[openstack-dev] [nova] Hard fail if you try to rename an AZ with instances in it?
jaypipes at gmail.com
Tue Mar 27 17:28:50 UTC 2018
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
> 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  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
> 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
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  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).
 Example of tribal knowledge is the fact that a single host aggregate
cannot have the multiple availability zone metadata items associated
 Or scrap nova host aggregates entirely and just move all this to the
placement service/database, adding a name and visibility column to the
More information about the OpenStack-dev