Open Stack

On Mar 26, 2014, at 11:40 AM, Jay Pipes <jaypipes at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140326/b3ab6615/attachment.pgp>