Open Stack

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 <dborodaenko at 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 <adidenko at 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 <sbrimhall at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev