Open Stack

Hi Jay,




-----Original Message-----
From: Jay Pipes [mailto:jaypipes at gmail.com] 
Sent: 18 January 2013 19:59
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 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.

Sorry I screwed up big time on my terminology there ;-(     by "Nova instance" in my head I meant "a collection of Nova services that share a database".     I'm not quite sure what to call that now - Region doesn't seem to really fit as with cells as region could be multiple sets of these whatever-we-callthems.

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

Well with the aggregate model it could be as a there's nothing other than sanity to constrain hosts to more than one aggregate - but that's just a rathole.

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

 Just to be sure we're aligned on terminology can you define what a region is in this context please.   Is it the API endpoint returned by keystone and everything behind it ?  Does a region always have one DB  in your model ?

And likewise how do you define an availability zone - you seem to see them as orthogonal to regions whereas I seem them as a subdivision of a region.

>> 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. 
Sorry - didn't mean to :-)

>Where do you get the information about the Nova endpoint (which as you say "has multiple availability zones")? Keystone.
Yep

> 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.
I'd find out by asking each region what azs it has.   I'm assuming that I've already chosen the region I want because of something I know about it (like where it is geographically).   Does your use case have it that a user is trying to choose a region based on what AZs it supports?   That seems to imply that AZs span regions in some way - "I want a region that has az1" seems to imply that either there is only one az1, or all az1's are the same - I don't see that. 
I think its more likely that I'll select a region that has some particular flavor available (maybe GCPUs) - should flavours be in keystone as well then ?



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

If they don't have the same properties then why not keep that specialisation as something that you can find out from the regions themselves ? 

Phil

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

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