On Sep 19, 2014, at 10:14 AM, John Dickinson <m...@not.mn> wrote:

> 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.
> 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.


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

OpenStack-dev mailing list

Reply via email to