Open Stack

Boris Renski Jr. wrote:
> 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. 
> [...]

You're not the first one to raise this discussion, so you're probably
not the only one bothered :) I think it's slightly disjoint from the
issue we've been prompted to discuss by the BoD, which is why I renamed
the thread for clarity.

> 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. 

I think that's been the prevailing view so far. Note that under the PPB
rule, we actually had a mechanism for removing/replacing projects from
core: just propose a motion and vote on it. With the current mix of
responsibilities (BoD/TC) around core it's a lot more undefined, but if
the direction separating responsibilities prevails, we should have a
clear mechanism again.

> 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.  

While I generally agree with your vision, I think reality is a bit more
complex. Even if Nova is more modular than Swift, it still has a fair
bit of opinionated implementation in it: yes you can switch hypervisors,
but it's not really a pure API layer with complete pluggable
implementation. I'm not sure it makes sense to generally take out the
external API layers from projects and make them all their own (very
small) projects. So it may not really be a question of API vs.
Implementation, but rather about being as pluggable and inclusive of
other technologies as possible.

-- 
Thierry Carrez (ttx)