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 of the EC2 availability zone concept in the Nova and Cinder APIs as just another example of implementation leaking out of the API. The fact that EC2 availability zones are implemented as independent failure domains and thus have a non-hierarchical structure has caused the Nova API to look and feel a certain way that locks the API into the implementation of a non-OpenStack product. Best, -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev