Open Stack

Hi Jay,

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 ?  

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 ?


There are things currently in Nova that I do believe should be in keystone, such as ssh keys (they're a property of a user - why do they live in Nova ?) - which would also fix the issue of how to make ssh keys work with cells.

I'm also thinking that aside from instance there shouldn't be anything in Nova that imposes access through direct association with a tenant, it should be associated with a role and keystone then controls the mapping of roles to tenants - so for example the API that allows a flavor to be restricted to a tenant should instead restrict it to a role.   

Cheers,
Phil


-----Original Message-----
From: Jay Pipes [mailto:jaypipes at gmail.com] 
Sent: 18 January 2013 16:11
To: OpenStack Development Mailing List
Subject: [openstack-dev] Listing regions and availability zones - Doesn't this belong in Keystone?

A couple folks have recently brought up why there isn't any ability in Nova to list the availability zones and show the AZ and region for an instance.

Phil Day shared the related blueprint [1] which led me to investigate one of the patches proposed for the blueprint for listing availability
zones:

https://review.openstack.org/#/c/19824/

I'd like to bring up a point that I think is important to address before such a patch is accepted.

Why is the listing of availability zones or regions an operation in Nova at all? This information more naturally belongs in Keystone.

Many installations of Nova (including ours) do not use one giant Nova database that stores data for instances in multiple availability zones.
To scale more effectively, we have a single Nova database for one availability zone in a region.

On the other hand, we have a singular Keystone database cluster that stores catalog information for more than one availability zone and more than one region. We do this to enable a unified authentication model across regions and AZs.

IMHO, it makes more sense to put operations for listing AZs and regions into Keystone since:

a) Keystone already has natural interfaces for returning service catalogs. Listing availability zones (and further, regions) is a natural extension of the service catalog.

b) Availability zones and regions apply to more than just Nova. At a minimum, volumes in Cinder are assigned in an availability zone.
Keystone advertises more endpoints than just Nova, so again it seems more natural to have Keystone advertise the availability zones and regions a tenant has access to.

Thoughts?
-jay

[1] https://blueprints.launchpad.net/nova/+spec/show-availability-zone

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