Open Stack

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