Open Stack

Since we are talking about OpenStack core and respective roles of TC and
board in helping define this, I have a matter up for discussion that's been
bothering me for some time. 

Today we have two types of projects that are core. Those where the bigger
emphasis is on the API and APIs are loosely coupled with the implementation
or even third party functionality or plug-ins (Nova, Quantum, Cinder) and
those that are really opinioned implementations of certain functionality -
Swift (probably the most pronounced member of the second category), Horizon
etc. 

For instance, similar to Quantum, Swift could have been designed as an API
centric service with implementations as plug-ins; but it is not. And largely
due to the history of how OpenStack evolved, Swift now became the monopoly
implementation on object store, indefinitely enjoying core project status.
It is not unlikely that Swift could become less active and its opinionated
architecture - less relevant to the newer paradigms of storage. More
importantly, because something like Swift is core, nobody in the community
would even consider developing a different, competing implementation.... 

I am not trying to pick on Swift in particular (so John, don't get mad) but
am using it to illustrate a scenario. 

I feel that as we rethink project categories, it make sense to incorporate
the distinction between developing an API standard and the underlying
implementation. And there are several ways we can go: 

1. We can say we don't care about the rigidity of coupling between API and
implementation in general. All we care about is if the project is mature
enough and if it solves a substantial IaaS problem.... in that case we need
to have a mechanism to deprecate projects from core when a particular
implementation is no longer optimal or if the project becomes inactive. 

2. We can say that we DO care about this and want to decouple APIs and
implementations as the underlying philosophy of all OpenStack projects. In
that case we need to make sure that ALL core (nucleus) projects are API
focused and designed to support various implementations as plug-ins, and
then have a separate, rather inclusive, category of projects that constitute
various mature implementations of the nucleus APIs that can be certified as
core, support etc.  

I haven't heard any of the core vs. not core discussion rotate around API
vs. implementation concept and would like to hear what people think. 

-Boris      


Anne Gentle wrote:
> I think there are projects that should be held to the requirements an
> integrated release has. They're probably all in nuclear and core.
> Perhaps nuclear is only helpful to scope release management, CI,
> integration testing, and doc. Hm. I would want "core" projects to get
> benefits from the systems we provide but not overwhelm them.

So, if I understand correctly, your motion would be a variation on
Mark's proposal where we would split the "services" category into two:
"core" and "nuclear", which would be prioritized slightly differently in
terms of associated common resources.

Those would still be technically-defined (under the authority of the TC)
in a way that is disconnected from trademark usage (although I suspect
it would be a good thing if Nuclear projects were all in the BoD
trademark scope).

I think that's definitely acceptable. A bit more bureaucracy on one side
(one additional project category) but it might end up being useful to
prioritize our resources if we grow the number of projects. Whether we
end up with one or two (or more) project categories is not actually that
important at this stage, that's just a technical way to name project
types under the TC's responsibility.

What we really need is a view on how to handle incubation and core
process together with the BoD, and on that point your motion is very
aligned with Mark's, as far as I can tell: separate the areas of
responsibility by handling trademark issues separately from which
project we grow under the OpenStack development umbrella.

Maybe we can merge the two motions by leaving the question of the number
of project categories for a future discussion ? I'm not sure it makes
sense to decide between the two variants until we know if the rest of
our position is acceptable by the BoD.

-- 
Thierry Carrez (ttx)