Granted conditionally, design consensus deadline March 10, merge deadline March 16 for patches that do not conflict with fuel-openstack-tasks and fuel-remove-conflict-openstack, March 24 for remaining patches.
If design consensus is not reached by March 10, the exception will be revoked. -- Dmitry Borodaenko On Wed, Mar 02, 2016 at 07:01:02AM -0700, Scott Brimhall wrote: > This is not possible to move to 10. This is a critical feature that > our 2 largest customers are dependent on for deployment at the end of > May. Puppet Master flat out will not work with a Fuel deployed > environment without doing this unless we were to create our own > composition layer, which would leave us with two separate code bases > to maintain. That isn't an option and this pretty much has to happen > in 9. > > --- > Scott Brimhall, Cloud Architect > Mirantis - Pure Play Openstack > > > On Mar 2, 2016, at 02:01, Aleksandr Didenko <adide...@mirantis.com> wrote: > > > > Hi, > > > > > Merging this code is relatively non-intrusive to core Fuel Library code > > > as it is merely re-organizing the file structure of the osnailyfacter > > > module to be compatible with Puppet Master. > > > > 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. > > > > 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. > > > > Regards, > > Alex > > > >> On Wed, Mar 2, 2016 at 1:21 AM, Scott Brimhall <sbrimh...@mirantis.com> > >> wrote: > >> Greetings, > >> > >> As you might know, we are working on integrating a 3rd party > >> configuration management platform (Puppet Master) with Fuel. > >> This integration will provide the capability for state enforcement > >> and will further enable "day 2" operations of a Fuel-deployed site. > >> We must refactor the 'osnailyfacter' module in Fuel Library to be > >> compatible with both a masterful and masterless Puppet approach. > >> > >> This change is required to enable a Puppet Master based LCM > >> solution. > >> > >> We request a FFE for this feature for 3 weeks, until Mar 24. By that > >> time, we will provide a tested solution in accordance with the following > >> specifications [1]. > >> > >> The feature includes the following components: > >> > >> 1. Refactor 'osnailyfacter' Fuel Library module to be compatible with > >> Puppet Master by becoming a valid and compliant Puppet module. > >> This involves moving manifests into the proper manifests directory > >> and moving the contents into classes that can be included by Puppet > >> Master. > >> 2. Update deployment tasks to update their manifest path to the new > >> location. > >> > >> Merging this code is relatively non-intrusive to core Fuel Library code > >> as it is merely re-organizing the file structure of the osnailyfacter > >> module to be compatible with Puppet Master. Upon updating the > >> deployment tasks to reflect the new location of manifests, this feature > >> remains compatible with the masterless puppet apply approach that > >> Fuel uses while providing the ability to integrate a Puppet Master > >> based LCM solution. > >> > >> Overall, I consider this change as low risk for integrity and timeline of > >> the release and it is a critical feature for the ability to integrate an > >> LCM > >> solution using Puppet Master. > >> > >> Please consider our request and share concerns so we can properly > >> resolve them. > >> > >> [1] > >> https://blueprints.launchpad.net/fuel/+spec/fuel-refactor-osnailyfacter-for-puppet-master-compatibility > >> > >> --- > >> Best Regards, > >> > >> Scott Brimhall > >> Systems Architect > >> Mirantis Inc > >> __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev