Re: [openstack-dev] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility
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 > > 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 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 > 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
Re: [openstack-dev] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility
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 > 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 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 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
Re: [openstack-dev] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility
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 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 > >> 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 __ Ope
Re: [openstack-dev] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility
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 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 >> 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
Re: [openstack-dev] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility
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 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-dev] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility
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
