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

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

OpenStack-dev mailing list

Reply via email to