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 >>> OpenStackfirstname.lastname@example.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 OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev