Open Stack

Hi Jay,

I'm not sure I follow your model of the relationship between AZs and different Nova Instances.

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".

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)

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 ?    
 
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.       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.   

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