Open Stack

On Thu, 2014-03-27 at 01:10 +0000, Joshua Harlow wrote:
> 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?

Precisely.

-jay

> 
> From: Jay Pipes <jaypipes at gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>
> Date: Wednesday, March 26, 2014 at 4:45 PM
> To: "openstack-dev at lists.openstack.org"
> <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> 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
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>         
>