<div dir="ltr"><div><div>Hi,<br><br>> Merging this code is relatively non-intrusive to core Fuel Library code<br>> as it is merely re-organizing the file structure of the osnailyfacter<br>> module to be compatible with Puppet Master. <br><br></div>It looks like super-intrusive to me. Modular manifests are, actually, the core of Fuel Library. And the majority of changes we introduce in Fuel Library are proposed for those manifests. So if you're going to move those manifests into "osnailyfacter::*" classes then it will basically conflict with the 90% of other patches for Fuel Library. This may slow down development of other features as well as bug fixing.<br></div><div><br>Also I see no patches on review and spec is not yet accepted. I think starting such an intrusive feature after FF is too risky, let's move it to 10.0.<br></div><div><br></div><div>Regards,<br></div><div>Alex<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 2, 2016 at 1:21 AM, Scott Brimhall <span dir="ltr"><<a href="mailto:sbrimhall@mirantis.com" target="_blank">sbrimhall@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings,<br>
<br>
As you might know, we are working on integrating a 3rd party<br>
configuration management platform (Puppet Master) with Fuel.<br>
This integration will provide the capability for state enforcement<br>
and will further enable "day 2" operations of a Fuel-deployed site.<br>
We must refactor the 'osnailyfacter' module in Fuel Library to be<br>
compatible with both a masterful and masterless Puppet approach.<br>
<br>
This change is required to enable a Puppet Master based LCM<br>
solution.<br>
<br>
We request a FFE for this feature for 3 weeks, until Mar 24.  By that<br>
time, we will provide a tested solution in accordance with the following<br>
specifications [1].<br>
<br>
The feature includes the following components:<br>
<br>
1. Refactor 'osnailyfacter' Fuel Library module to be compatible with<br>
Puppet Master by becoming a valid and compliant Puppet module.<br>
This involves moving manifests into the proper manifests directory<br>
and moving the contents into classes that can be included by Puppet<br>
Master.<br>
2. Update deployment tasks to update their manifest path to the new<br>
location.<br>
<br>
Merging this code is relatively non-intrusive to core Fuel Library code<br>
as it is merely re-organizing the file structure of the osnailyfacter<br>
module to be compatible with Puppet Master.  Upon updating the<br>
deployment tasks to reflect the new location of manifests, this feature<br>
remains compatible with the masterless puppet apply approach that<br>
Fuel uses while providing the ability to integrate a Puppet Master<br>
based LCM solution.<br>
<br>
Overall, I consider this change as low risk for integrity and timeline of<br>
the release and it is a critical feature for the ability to integrate an LCM<br>
solution using Puppet Master.<br>
<br>
Please consider our request and share concerns so we can properly<br>
resolve them.<br>
<br>
[1] <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-refactor-osnailyfacter-for-puppet-master-compatibility" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-refactor-osnailyfacter-for-puppet-master-compatibility</a><br>
<br>
---<br>
Best Regards,<br>
<br>
Scott Brimhall<br>
Systems Architect<br>
Mirantis Inc<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>