Re: [openstack-dev] [puppet] Clarification of 'Puppet Modules' Project Scope
Emilien Macchi wrote: I have a preference for #1 since IMHO it makes more sense for Midokura to have their Puppet module close to their code but I would not be against having it on Stackforge. [...] If you look at contributors [1], the history shows that this module has been written by people working on Puppet OpenStack modules and it made sense to have this repository on Stackforge to benefit of OpenStack integration. Until recently, puppet-vswitch was a dependency to run puppet-neutron. See [2]. [1]https://github.com/openstack/puppet-vswitch/graphs/contributors [2] https://github.com/openstack/puppet-neutron/tree/stable/juno/manifests/plugins/ovs To be less specific, Puppet modules that reside in OpenStack namespace aretoday: * deploying an OpenStack project (neutron, horizon, etc) * a dependency to deploy modules (openstacklib, vswitch) * contain some code used by our community to help with CI, documentation, consistency, etc (modulesync, cookiebutter, integration, blueprints). Emilien, Thank you for the input on this. The criteria you listed above seem totally reasonable, and based upon them, I can understand the reason for not bringing this module into the OpenStack namespace. Just to re-state the criteria to ensure my own understanding: --- OpenStack Puppet Modules: For a module to become part of the OpenStack Puppet Modules project it should meet one of the following requirements: 1) Provides configuration management capability for an OpenStack project. 2) Satisfies a dependency for deploying module(s) which conform to #1 above. 3) Assists in the creation, documentation, lifecycle-management, and testing for modules which conform to #1 above. StackForge Modules: For a module to become part of the StackForge project it should meet one of the following requirements: 1) Provides configuration management capability for one or more OpenStack-related project. 2) Provides configuration management capability for a project which is intending to become part of OpenStack. Proprietary Modules: For modules not meeting any of the above-outlined requirements, we suggest that it live in its own vendor-provided project or repository, and not utilize the OpenStack-infra provided CI and tooling. --- Does this seem to capture all the relevant pieces to you? Regards, Richard __ 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] [puppet] Clarification of 'Puppet Modules' Project Scope
I'm torn on this. Pedantically option A makes the most sense, but option B gives us more control over the supporting modules. I like having OpenStack CI run on vswitch and ceph rather than the typical github merge process. On Mon, Jun 22, 2015 at 11:05 AM, Richard Raseley rich...@raseley.com wrote: I am currently hoping to build consensus (or seek clarity if I am the only one with this question) about the appropriate scope for our 'Puppet Modules' project. The question in my mind is if we: A) Only include those modules which represent a 1:1 mapping with other OpenStack projects. B) Also include those modules which provide 'supporting' infrastructure to OpenStack components. To be totally transparent, this came to mind for me because I am currently working with the folks at Midokura to publish a module which can be used to configure their open source Midonet SDN for Neutron and I was contemplating whether or not it would be reasonable to be part of the project. FWIW, we have carried over the 'puppet-vswitch' repository over with us as part of the move (which would align with option B), but I didn't want to assume that was intended to be precedent setting. Regards, Richard __ 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] [puppet] Clarification of 'Puppet Modules' Project Scope
I am currently hoping to build consensus (or seek clarity if I am the only one with this question) about the appropriate scope for our 'Puppet Modules' project. The question in my mind is if we: A) Only include those modules which represent a 1:1 mapping with other OpenStack projects. B) Also include those modules which provide 'supporting' infrastructure to OpenStack components. To be totally transparent, this came to mind for me because I am currently working with the folks at Midokura to publish a module which can be used to configure their open source Midonet SDN for Neutron and I was contemplating whether or not it would be reasonable to be part of the project. FWIW, we have carried over the 'puppet-vswitch' repository over with us as part of the move (which would align with option B), but I didn't want to assume that was intended to be precedent setting. Regards, Richard __ 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] [puppet] Clarification of 'Puppet Modules' Project Scope
Hi Richard, On 06/22/2015 01:05 PM, Richard Raseley wrote: I am currently hoping to build consensus (or seek clarity if I am the only one with this question) about the appropriate scope for our 'Puppet Modules' project. The question in my mind is if we: A) Only include those modules which represent a 1:1 mapping with other OpenStack projects. B) Also include those modules which provide 'supporting' infrastructure to OpenStack components. To be totally transparent, this came to mind for me because I am currently working with the folks at Midokura to publish a module which can be used to configure their open source Midonet SDN for Neutron and I was contemplating whether or not it would be reasonable to be part of the project. I see two options here: #1 you create the repository outside Stackforge OpennStack, on your own repo or in Midokura namespace. #2 you create the repository on Stackforge (like puppet-ceph) but Puppet OpenStack group won't officially support it for the simple reason it's not an OpenStack project or a dependency to deploy it. I would be against having puppet-midonet part of OpenStack namespace though for the same reasons it could be on Stackforge. I have a preference for #1 since IMHO it makes more sense for Midokura to have their Puppet module close to their code but I would not be against having it on Stackforge. FWIW, we have carried over the 'puppet-vswitch' repository over with us as part of the move (which would align with option B), but I didn't want to assume that was intended to be precedent setting. If you look at contributors [1], the history shows that this module has been written by people working on Puppet OpenStack modules and it made sense to have this repository on Stackforge to benefit of OpenStack integration. Until recently, puppet-vswitch was a dependency to run puppet-neutron. See [2]. [1] https://github.com/openstack/puppet-vswitch/graphs/contributors [2] https://github.com/openstack/puppet-neutron/tree/stable/juno/manifests/plugins/ovs To be less specific, Puppet modules that reside in OpenStack namespace are today: * deploying an OpenStack project (neutron, horizon, etc) * a dependency to deploy modules (openstacklib, vswitch) * contain some code used by our community to help with CI, documentation, consistency, etc (modulesync, cookiebutter, integration, blueprints). Any feedback is welcome, Regards, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ 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
