Open Stack

On 09/19/2014 10:14 AM, John Dickinson wrote:
> 
> 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.

I like where you're going with this - although in the context of my
reponse to ttx, I kinda think he makes a good point about the effect of
TC granted 'themes' or whatnot (vish's thought on self-organization
notwithstanding) In as much as a definition and codification may result
in eventual exclusivity of thought, I think we should be careful, but it
does have it's place.

I've kinda been thinking since we spoke at OpenStackSV that there is an
opportunity here for something akin to what you and Vish are talking
about to be the entry point for the "product management" point of view
people have been calling for.

Specifically, if we start with layer 1/ring 0 as a "blessed" use case
that we know we have to deliver - then people - me, you or some product
manager - can, as the spirit strikes them, propose additional ones.

For instance, I don't think "storage" is great - because swift, cinder,
manila and trove are all wildly different and solve different end user
needs. I'd actually argue that nova, swift and zaqar might be components
in a "I want to use ephemeral nova with object storage and queing to
build an app"

I'm waving my hands here wildly because I don't know what the next thing
past layer #1 that we want to explicitly call out as essential might be,
or when we'll feel we're ready to label it and point our fingers at it
... but I do think it's important to both leave the door open for that
to happen and to be prepared for it.

Something DEFINITELY needs to change in the realm of program structure
though.