Stop accepting to update AZ names if instances are there already

Registered by Sylvain Bauza on 2017-03-16

Availability zones (AZs) are just an abstract API model that doesn't correspond to some real object on the Nova side. Rather, it's just a Facade for exposing to end-users the value of a specific aggregate metadata key and thus allow end-users to play with aggregates using certain rules.

The fact is that it's possible for an end-user to list all the availability zones and accordingly boot instances on some AZs.
Unfortunately, as an operator can modify any metadata, it is possible to change the value of the availability_zone key for a specific aggregate and accordingly change what the user can see when looking at AZs.
As a consequence, it's highly confusing. Say I'm Alice and I want to boot an instance on AZ foo, I do that.
Then, 2 weeks after, I want to start yet another server and I'm looking up at AZ foo but can't find it. Why ? Eh, wait? Why my existing server is in AZ 'bar' ?

See, there are a ton of implications when changing an AZ name. For example, yet another problem would be that Bob who is admin wanted to have all the instances be in a specific AZ by default, so he gently did set default_schedule_zone to "foo".
Unfortunately, Charlie wanted to rename "foo" into "bar". He did that, so kabooooom for all new instances which can't find "foo".

All of that is very error-prone and since we don't expose the aggregate UUID for knowing the real value of an AZ, the only unique identifier is the name. Yeah, terrible.

So, I'm proposing to provide a new microversion and return an invalid aggregate update action if existing instances are running (by modifying nova.compute.api._is_safe_to_update_az).

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
Sylvain Bauza
Direction:
Needs approval
Assignee:
Sylvain Bauza
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Matt Riedemann on 2019-02-06

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/az-block-name-update,n,z

Addressed by: https://review.openstack.org/446446
    Proposed block accepting AZ renames

We agreed at the Stein PTG to just block AZ renames if the AZ has instances in it and do that as a bug fix, not a microversioned API change so I'm going to mark this blueprint as obsolete. -- mriedem 20190206

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.