Open Stack

On Sep 19, 2014, at 10:14 AM, John Dickinson <me at not.mn> 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.
> 
> 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

There is a pretty different division of things in this breakdown than in what monty was proposing. This divides things up by conceptual similarity which I think is actually less useful than breaking things down by use case. I really like the grouping and testing of things which are tightly coupled.

If we say launching a VM and using it is the primary use case of our community corrently then things group into monty’s layer #1. It seems fairly clear that a large section of our community is focused on this use case so this should be a primary focus of infrastructure resources.

There are other use cases in our community, for example:

Object Storage: Swift (depends on keystone)
Orchestrating Multiple VMs: Heat (depends on layer1)
DBaSS: Trove: (depends on heat)

These are also important use cases for parts of our community, but swift has demostrated that it isn’t required to be a part of an integrated release schedule, so these could be managed by smaller groups in the community. Note that these are primarily individual projects today, but I could see a future where some of these projects decide to group and do an integrated release. In the future we might see (totally making this up):

Public Cloud Application services: Trove, Zaqar
Application Deployment services: Heat, Murano
Operations services: Ceilometer, Congress

As I mentioned previously though, I don’t think we need to define these groups in advance. These groups can organize as needed.

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