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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
