Open Stack

John Dickinson wrote:
> I propose that we can get the benefits of Monty's proposal and implement all of his concrete suggestions (which are fantastic) by slightly adjusting our usage of the program/project concepts.
> 
> I had originally hoped that the "program" concept would have been a little higher-level instead of effectively spelling "project" as "program". I'd love to see a hierarchy of openstack->program->project/team->repos. Right now, we have added the "program" layer but have effectively mapped it 1:1 to the project. For example, we used to have a few repos in the Swift project managed by the same group of people, and now we have a few repos in the "object storage" program, all managed by the same group of people. And every time something is added to OpenStack, its added as a new program, effectively putting us exactly where we were before we called it a program with the same governance and management scaling problems.
> 
> Today, I'd group existing OpenStack projects into programs as follows:
> 
> Compute: nova, sahara, ironic
> Storage: swift, cinder, glance, trove
> Network: neutron, designate, zaqar
> Deployment/management: heat, triple-o, horizon, ceilometer
> Identity: keystone, barbican
> Support (not user facing): infra, docs, tempest, devstack, oslo
> (potentially even) stackforge: lots

I'm not clear on what those $THINGS would actually represent.

Would they have a single PTL ? (I guess not, otherwise we are back at
the team/theme duality I called out in my answer to Monty). Who decides
which $THINGS may exist ? (I suppose anybody can declare one, otherwise
we are back with TC blessing fields). Can $THINGS contain alternative
competing solutions ? (I suppose yes, otherwise we are back to
preventing innovation).

So what are they ? A tag you can apply to your project ? A category you
can file yourself under ?

I like Monty's "end-user" approach to defining layer #1. The use case
being, you want a functioning compute instance. Your taxonomy seems more
artificial. Swift, Cinder, Glance and Trove (and Manila) all represent
very different end-user use cases. Yes they all "store" stuff, but
that's about the only thing they have in common. And no user in their
sane mind would use all of them at the same time (if they do, they are
probably doing it wrong).

I guess we could recognize more "basic use cases". I.e. Object storage
is a end-user use case all by itself, and it only requires Swift +
Keystone. So we could have a Layer #1bis that is Swift + Keystone. But
then we are back to blessing stuff as essential/official, and next thing
we know, Sahara will knock on the TC door to get Map/Reduce recognized
as essential layer-1-like end-user use case.

I can see how a "give-me-a-damn-instance" layer-1 definition is
restrictive, but that's the beauty and the predictability of Monty's
proposal. It limits integration where it really matters, unleashes
competition where it will help, and removes almost all of the
badge-granting role of the TC.

-- 
Thierry Carrez (ttx)