Open Stack

On 01/18/2013 02:36 PM, Day, Phil wrote:
> Hi Jay,
> 
> I'm not sure I follow your model of the relationship between AZs and different Nova Instances.

A nova instance is a VM... a server.

> As things stand today, If I have two separate Nova instances they might both have AZs in them called "az1" and "az2".   Does that mean that "az1" in both of them is the same AZ ?    I think the answer is "it depends".

A VM cannot be in two AZs...

> First off I guess we have to define what it means for them to be the same - logically to the user I would expect it to mean that that have a common failure mode (since that's really what they're trying to avoid) - so if the two Nova instances were in the same data center then yes its likely that nova_1.az1 and nova_2.az1 are pools of hosts that are in the same data hall  (although in this case I'm not sure why you wouldn't implement these as cells so they appear as a single region)

Again, this isn't about Nova. It is about the listing of availability
zones and regions for a global deployment of OpenStack.

> But If I have two Nova instances that are on other sides of the country, for example nova_west and nova_east, and they both also have an az1 and az2 it doesn't follow that nova_east.az1 and nova_wast.az1 have some common failure mode and are therefore part of the same availability zone.   But both of those nova_west and nova_east  could be part of the same keystone instance (just different service points), so where does that leave the list of AZs ?    

You are describing regions and availability zones. nova_west and
nova_east are regions. Availability zones could indeed be named the same
within different regions. That is fine. But that is also why I am saying
we need a service other than the Nova database inside a particular
region or availability zone that has information about ALL the regions
and the availability zones in those regions. Necessarily, this cannot be
in just one of the Nova databases, and since Keystone is naturally a
place to put universal information, I believe it is the better fit.

Cells have nothing to do with this.

> At the moment the only property of an AZ that needs to be visible is its name - and the only reason that as a user that I need a list of az names associated to a particular nova end point is so that I know which ones I can chose between when creating instances.

You are proving my point. Where do you get the information about the
Nova endpoint (which as you say "has multiple availability zones")?
Keystone. And how do you know where to find a list of regions that have
availability zones? There isn't currently a way. And I think keystone is
the best fit to add that information -- which is really meta-information
about a global deployment of OpenStack -- into.

>Keystone will give me a list of compute services (regions) - but I
don't think there should be a constraint that says that each of those
regions will always have all the same properties (flavours, images,
azs)? Unless you impose that constraint then keystone will have to keep
some mapping of which azs are in which region, which is a view of the
truth that you can get just as easily by iterating through the regions
and asking each one for its list of AZs.

I don't know where you are getting the idea that I am saying all regions
will have the same properties...

-jay

> Maybe I'm missing your use case completely here ?
> 
> Cheers,
> Phil
> 
> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com] 
> Sent: 18 January 2013 18:51
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] Listing regions and availability zones - Doesn't this belong in Keystone?
> 
> On 01/18/2013 01:11 PM, Day, Phil wrote:
>> I'm not convinced yet that AZ information belongs in Keystone.    Membership of an AZ is fundamentally an attribute of a compute host, and no other information about hosts is stored in keystone, so why should this one be ?
> 
> Where should the availability zones table (and regions table) exist, then? If it exists in the Nova database, then you need to duplicate the table in all the Nova databases in all your availability zones, unless of course, you have one giant database for all compute stuff (not recommended, and I know this isn't how HP Cloud is doing it...)
> 
> You need a single source of truth for an organizations regions and availability zones. The only thing that should be stored in Nova is the foreign key for the AZ/region, not the AZ or region table themselves.
> 
> This single source of truth for availability zones and regions, I believe, more naturally fits into Keystone, which is the data store that most often will be the thing that an organization shares between availability zones and regions.
> 
>> Keystone keeps details of tenants and service endpoints.   Once you have a service endpoint you get other details (such as what flavours it supports) by querying the service itself, so why is availability zones any different ?
> 
> You are mistaking showing the availability zone for a compute instance with listing ALL availability zones/regions. It is the latter to which I am referring in this thread. A service endpoint that serves a single region or availability zone cannot, by nature, be the source of information about other availability zones/regions.
> 
> Best,
> -jay
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>