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. Hierarchical doesn’t work for the rack/switch model. 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 is also unfortunate that region already has a meaning in the amazon world which will add confusion. Vish > > 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
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
