Open Stack

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