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
