On Sep 19, 2014, at 5:46 AM, John Griffith <john.griff...@solidfire.com> wrote:

> On Fri, Sep 19, 2014 at 4:33 AM, Thierry Carrez <thie...@openstack.org> wrote:
> Vishvananda Ishaya wrote:
> > Great writeup. I think there are some great concrete suggestions here.
> >
> > A couple more:
> >
> > 1. I think we need a better name for Layer #1 that actually represents what 
> > the goal of it is: Infrastructure Services?
> > 2. We need to be be open to having other Layer #1s within the community. We 
> > should allow for similar collaborations and group focus to grow up as well. 
> > Storage Services? Platform Services? Computation Services?
> I think that would nullify most of the benefits of Monty's proposal. If
> we keep on blessing "themes" or special groups, we'll soon be back at
> step 0, with projects banging on the TC door to become special, and
> companies not allocating resources to anything that's not special.
> --
> Thierry Carrez (ttx)
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ​Great stuff, mixed on point 2 raised by Vish but honestly I think that's 
> something that could evolve over time, but I looked at that differently as in 
> Cinder, SWIFT and some day Manilla live under a Storage Services umbrella, 
> and ideally at some point there's some convergence there.
> Anyway, I don't want to start a rat-hole on that, it's kind of irrelevant 
> right now.  Bottom line is I think the direction and initial ideas in Monty's 
> post are what a lot of us have been thinking about and looking for.  I'm in!!​

I too am generally supportive of the concept, but I do want to think about the 
vishy/tts/jgriffith points above.

It's interesting that the proposed "layer #1" stuff is very very similar to 
what was originally in OpenStack at the very beginning as Nova. Over time, many 
of these pieces of functionality required for compute were split out (block, 
networking, image, etc), and I think that's why so many people look at these 
pieces and say (rightly), "of course these are required all together and 
tightly coupled". That's how these projects started, and we still see evidence 
of their birth today.

For that reason, I do agree with Vish that there should be similar 
collaborations for other things. While the "layer #1" (or "compute") use case 
is very common, we can all see that it's not the only one that people are 
solving with OpenStack parts. And this is reflected in the products build and 
sold by companies, too. Some sell one subset of openstack stuff as product X 
and maybe a different subset as product Y. (The most common example here is 
"compute" vs "object storage".) This reality has led to a lot of the angst 
around definitions since there is effort to define openstack all as one thing 
(or worse, as a "base" thing that others are defined as built upon).

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 like two things about this. First, it allows people to compose a solution. 
Second, it allows us as a community to thing more about the strategic/product 
things. For example, it lets us as a community say, "We think storage is 
important. How are we solving it today? What gaps do we have in that? How can 
the various storage things we have work together better?"

Thierry makes the point that more "themes" will nullify the benefits of Monty's 
proposal. I agree, if we continue to allow the explosion of 
projects/programs/themes to continue. The benefit of what Monty is proposing is 
that it identifies and focusses on a particular use case (deploy a VM, add a 
volume, get an IP, configure a domain) so that we know we have solved it well. 
I think that focus is vital, and by grouping OpenStack into the high-level 
themes (ie programs), we provide this in two ways.

First, we can look at a particular program like storage and examine for gaps 
(we provide a way to provision DBs but should we also provide a way to do 
dynamo DB?). This means that as a community we can have a good, long-term view 
of the problems we are solving and the ones we want to solve.

Second, the high-level program concept means that we can add more projects (ie 
teams) without having to worry about also adding to the number of programs. 
This helps organization, summit scheduling, and other pain points we've had 
with the huge number of teams and the pressure to add more.

Overall, I love the discussion and think that Monty's concrete suggestions are 
great. I think that slightly adjusting the existing concepts we already have 
can allow us to continue to effectively grow the community without creating a 
caste system of teams and gives us the ability to make longer-term, strategic 


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

OpenStack-dev mailing list

Reply via email to