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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
