openstack-poc team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

Joe Heck wrote:
> [...]
> Here's a strawman (that I'm sure will get some comments) to try and nail down some definitions and differences for some of these terms:
> [...]

Generally in agreement with you, a few comments below.

> "OFFICIAL"
> ==========
> 
> Four "things" that are clearly a "part" of OpenStack, but aren't "core":
> 
>  - CI, being run/lead by Monty
>  - Devstack, and I've no idea who's coordinating that
>  - Docs, being run/lead by Anne
>  - Web/Community, being run/lead by Stefano (i.e. the public website of openstack)
>  - QA/Tempest, being run/lead by Jay and/or Darryl (I'm honestly not sure)

+1

As far as devstack goes, I think the only reason it's included here (and
not the evergrowing list of other community options to deploy OpenStack)
is that it's used as a gating mechanism. If for some reason we switch to
something else (or add something else), it should be an official project
instead/too.

> "COMMUNITY"
> ============
> 
> Everything else - additional APIs that map to the OpenStack kernel, proprietary plugins that provide services or functionality to core pieces (like Keystone and Quantum plugins, Volume drivers) actually have FAR more benefit by NOT being core.
> 
> Key differences:
>  * We should provide a means to make these pieces/projects/etc discoverable, and very easily. (and I think we all agree, and Monty is doing some "forge" thing website to make this happen as I understand)
>  * The release cycle of these components is completely independent of releases of OpenStack
>  * Compatibility is the responsibility of the community project, and we don't gate changes to future work in OpenStack based on it potentially breaking a community project
>  * These projects don't need to be open source
>  * These projects don't need to be controlled or mandated by OpenStack as an organization or community
>  * These projects are where most of the value-add for using OpenStack will be most clear.
>  * OpenStack "CORE" is the kernel being made to support *THIS* set of projects - in the kernel/userland metaphor, this is userland. This is where a thousand flowers bloom.

So the difference between (b) and (c) is about supporting (or not
supporting) additional adjectives to the "Community" group (starred,
tested, certified, compatible, recommended...), based on extra
tests/QA-integration/mojo they provide and we recognize. We can do (b)
and then evolve into (c), but not the other way around :)

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack