Open Stack

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