Open Stack

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

> 
> 
> On Fri, Sep 19, 2014 at 4:33 AM, Thierry Carrez <thierry at 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 at 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 plans.


--John




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140919/91a1fa69/attachment.pgp>