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...
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
