Open Stack

Mark McClain wrote:
> I like the idea of a Quantum ecosystem repo because it provides a
> catalog of available software and fits within the notion that OpenStack
> should have a focused core interface: compute, networking, and storage.
>  The ecosystem also promotes a healthy platform layer that is built upon
> the core.

That directly relates to the other discussion on what Core is vs. what
OpenStack promotes vs. what is developed within the OpenStack
development infrastructure. I expect the options on the table to change
a bit once that's solved.

> The ecosystem solves several current issues:
> - Plugin reviews take time away from core and community bugs/blueprints
> - Plugins/drivers that require physical devices are hard to
> realistically validate.
> - An ecosystem repo places the onus on quality/working code back on the
> vendor/project promoting it.
> - Code bloat within the main repository as vendor push code for visibility.
> - Platform projects do not have a visible place to grow around Quantum
> (e.g. DNSaaS).
> 
> Separate repos would be the ideal setup, but that will take significant
> resources. We could start with a contrib directory within Quantum.

I agree that ecosystem projects could have relaxed constraints compared
to core, and I like how that solves current issues. That said, I'm not
convinced that shipping them in a contrib directory under the main
source tree is the solution. I prefer to have code with the same
expectations of quality under a given source tree / in a given source
tarball. For example, where does security support end ? We put the
openstack seal on those tarballs and they come with a contract on stable
maintenance and security updates. Including code that lives under
different rules in them is very confusing.

I hope we can come up with a good mechanism (stackmeat or other) that
would solve the publicity and discovery of the ecosystem projects
without having to reuse a solution of the 80s.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack