Open Stack

On Wed, 2014-03-26 at 13:33 -0700, Vishvananda Ishaya wrote:
> 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.

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