Open Stack

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