On Thu, 2014-03-27 at 01:10 +0000, Joshua Harlow wrote: > Region graphs? > > Sounds like what u are describing sounds like a graph > (non-hierarchical) which has nodes that have defined attributes on > them. > > A region then would just be a set of connected nodes (which could be > connected via a parent<->child edge for example). > > Each node can also have attributes (allowing regions to also be > selected by common attributes). Seems like that might fit what is > wanted?
Precisely. -jay > > From: Jay Pipes <jaypi...@gmail.com> > Reply-To: "OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > Date: Wednesday, March 26, 2014 at 4:45 PM > To: "openstack-dev@lists.openstack.org" > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and > Host aggregates.. > > > > On Wed, 2014-03-26 at 13:33 -0700, Vishvananda Ishaya wrote: > On Mar 26, 2014, at 11:40 AM, Jay Pipes > <jaypi...@gmail.com> wrote: > > > On Wed, 2014-03-26 at 09:47 -0700, Vishvananda > Ishaya wrote: > >> Personally I view this as a bug. There is no reason > why we shouldn’t > >> support arbitrary grouping of zones. I know there > is at least one > >> problem with zones that overlap regarding > displaying them properly: > >> > >> https://bugs.launchpad.net/nova/+bug/1277230 > >> > >> There is probably a related issue that is causing > the error you see > >> below. IMO both of these should be fixed. I also > think adding a > >> compute node to two different aggregates with azs > should be allowed. > >> > >> It also might be nice to support specifying > multiple zones in the > >> launch command in these models. This would allow > you to limit booting > >> to an intersection of two overlapping zones. > >> > >> A few examples where these ideas would be useful: > >> > >> 1. You have 3 racks of servers and half of the > nodes from each rack > >> plugged into a different switch. You want to be > able to specify to > >> spread across racks or switches via an AZ. In this > model you could > >> have a zone for each switch and a zone for each > rack. > >> > >> 2. A single cloud has 5 racks in one room in the > datacenter and 5 > >> racks in a second room. You’d like to give control > to the user to > >> choose the room or choose the rack. In this model > you would have one > >> zone for each room, and smaller zones for each > rack. > >> > >> 3. You have a small 3 rack cloud and would like to > ensure that your > >> production workloads don’t run on the same machines > as your dev > >> workloads, but you also want to use zones spread > workloads across the > >> three racks. Similarly to 1., you could split your > racks in half via > >> dev and prod zones. Each one of these zones would > overlap with a rack > >> zone. > >> > >> You can achieve similar results in these situations > by making small > >> zones (switch1-rack1 switch1-rack2 switch1-rack3 > switch2-rack1 > >> switch2-rack2 switch2-rack3) but that removes the > ability to decide to > >> launch something with less granularity. I.e. you > can’t just specify > >> ‘switch1' or ‘rack1' or ‘anywhere’ > >> > >> I’d like to see all of the following work > >> nova boot … (boot anywhere) > >> nova boot —availability-zone switch1 … (boot it > switch1 zone) > >> nova boot —availability-zone rack1 … (boot in rack1 > zone) > >> nova boot —availability-zone switch1,rack1 … (boot > > > > Personally, I feel it is a mistake to continue to > use the Amazon concept > > of an availability zone in OpenStack, as it brings > with it the > > connotation from AWS EC2 that each zone is an > independent failure > > domain. This characteristic of EC2 availability > zones is not enforced in > > OpenStack Nova or Cinder, and therefore creates a > false expectation for > > Nova users. > > > > In addition to the above problem with incongruent > expectations, the > > other problem with Nova's use of the EC2 > availability zone concept is > > that availability zones are not hierarchical -- due > to the fact that EC2 > > AZs are independent failure domains. Not having the > possibility of > > structuring AZs hierarchically limits the ways in > which Nova may be > > deployed -- just see the cells API for the > manifestation of this > > problem. > > > > I would love it if the next version of the Nova and > Cinder APIs would > > drop the concept of an EC2 availability zone and > introduce the concept > > of a generic region structure that can be infinitely > hierarchical in > > nature. This would enable all of Vish's nova boot > commands above in an > > even simpler fashion. For example: > > > > Assume a simple region hierarchy like so: > > > > regionA > > / \ > > regionB regionC > > > > # User wants to boot in region B > > nova boot --region regionB > > # User wants to boot in either region B or region C > > nova boot --region regionA > > I think the overlapping zones allows for this and also > enables additional use > cases as mentioned in my earlier email. > > > You are assuming that the region hierarchy I was describing > had only a > single root region. I didn't say that. I envision multiple > root regions, > which would enable compute nodes to reside in multiple > regions. > > > Hierarchical doesn’t work for the > rack/switch model. > > > Sure it does. Just not a single root hierarchy. > > > I’m definitely +1 on breaking from the amazon usage > of availability zones but I’m a bit leery to add > another parameter to > the create request. > > > It wouldn't add another *required* parameter to the create > request. The > region would default to whatever region the keystone endpoint > that > returned the service catalog for the novaclient had as its > default > region. > > > It is also unfortunate that region already has a > meaning > in the amazon world which will add confusion. > > > OK. We could call it something else... though IIRC, trying to > come up > with a name for this kind of thing is, well, kind of tough :) > > > -jay > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev