Hi Dmitry, We have reached design agreement on this feature as of this morning, March 10th. The spec has been accepted and the test/merge plan presented for remaining patches by March 24 was agreed upon. Can the conditional status of the FFE request be removed, please?
Thanks, Scott Brimhall > On Mar 3, 2016, at 5:22 PM, Dmitry Borodaenko <dborodae...@mirantis.com> > wrote: > > 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 __________________________________________________________________________ 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