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. Vish
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
