Granted, merge deadlines are still as defined below: March 16 and 24. For the record, the spec for this feature: https://review.openstack.org/284853
The spec has positive votes from fuel-library CL and cores, so consensus is indeed reached. Get a +1 from the fuel-python CL and I'll merge it. -- Dmitry Borodaenko On Thu, Mar 10, 2016 at 10:29:15AM -0700, Scott Brimhall wrote: > 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 __________________________________________________________________________ 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