Open Stack

On 03/27/2018 12:42 PM, Matt Riedemann wrote:
> On 3/27/2018 10:37 AM, Jay Pipes wrote:
>> If we want to actually fix the issue once and for all, we need to make 
>> availability zones a real thing that has a permanent identifier (UUID) 
>> and store that permanent identifier in the instance (not the instance 
>> metadata).
> 
> Aggregates have a UUID now, exposed in microversion 2.41 (you added it). 
> Is that what you mean by AZs having a UUID, since AZs are modeled as 
> host aggregates?

Kind of. AZs are not actually a "thing" in Nova, as you know. They are 
just a hacked-up key/value metadata item on the nova host aggregate that 
has some "special" meaning and tribal knowledge [0] associated with it.

And, of course, nova host aggregates are not visible to normal end 
users, which makes the coupling of AZ to host aggregate metadata even 
more hacky.

> One of the alternatives in the spec is not relying on name as a unique 
> identifier and just make sure everything is held together via the 
> aggregate UUID, which is now possible.

A few things are needed:

1) Stop *referring* to the AZ by name in the instance_metadata item 
corresponding to the availability_zone key. Instead, use the aggregate's 
UUID.

2) Stop using the instance_metadata to store this information. On nova 
boot --availability-zone=$ZONE_NAME, nova-api should look up the 
aggregate having the name of $ZONE_NAME, and store the internal 
aggregate ID in a new instance_mappings.availability_zone_id column. The 
UUID of this aggregate should be placed into a new 
build_requests.availability_zone_uuid column/attribute and passed along 
through the scheduler to the cell control plane, where it should be 
stored in the cell DB's instances table as a new field 
"availability_zone_uuid". In this way, outside of the Nova API database 
we always refer to the availability zone using the external UUID, never 
the name or the internal ID.

3) Add an attribute to the nova API database aggregates [1] table called 
"visibility" that can indicate whether the aggregate is publicly-visible 
or not. That way, the operator can establish groups of compute resources 
that can be viewed by a normal end user (availability zones, regions, 
sub-regions, power-domains, whatever they want).

Best,
-jay

[0] Example of tribal knowledge is the fact that a single host aggregate 
cannot have the multiple availability zone metadata items associated 
with it: 
https://github.com/openstack/nova/blob/97042c0253be345beff3b99d08988cf95f60e759/nova/compute/api.py#L5066-L5083

[1] Or scrap nova host aggregates entirely and just move all this to the 
placement service/database, adding a name and visibility column to the 
placement_aggregates table...