Open Stack

Apologies for the curt reply but I'm on an iPhone right now. Cinder
and other services may require availability zones. Keystone is a good
central registry for looking these kinds of things up.

Sent from my iPhone

On Jan 18, 2013, at 12:16, "Day, Phil" <philip.day at hp.com> wrote:

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev