Open Stack

Region graphs?

Sounds like what u are describing sounds like a graph (non-hierarchical) which has nodes that have defined attributes on them.

A region then would just be a set of connected nodes (which could be connected via a parent<->child edge for example).

Each node can also have attributes (allowing regions to also be selected by common attributes). Seems like that might fit what is wanted?

From: Jay Pipes <jaypipes at gmail.com<mailto:jaypipes at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, March 26, 2014 at 4:45 PM
To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..

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<mailto: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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140327/d5802391/attachment-0001.html>