Open Stack

On 09/19/2014 10:50 AM, Vishvananda Ishaya wrote:
> 
> 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.

I'm kinda interested to see what self-organization happens...