| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a user shelve offloads a server, the compute manager
nulls out the instance host and node attributes. However
the availability_zone attribute is left set on the instance
so the API will show the instance as in an AZ when really
it's not, because an instance that is not on a host is not
in a host aggregate so it can't be in an AZ.
Keep in mind that there are two ways an instance can be in
an AZ:
1. The user specifically requests to create the server in
the AZ.
2. The user does not request an AZ and one is assigned via
the selected host during server create (or resize, etc).
For the first case, the server will always remain in the
user-requested AZ even after shelve/unshelve. But in the
second case, unshelving the server can result in the server
being spawned on a new host in a different AZ - the scheduler
does not restrict the AZ in that second case.
This change nulls out the instance.availability_zone just like
the host and node fields on shelve offload since it's
confusing to show a shelved offloaded server in an AZ that
doesn't have a host.
Final note: the _nil_out_instance_obj_host_and_node method
is also called during server create if the build fails and
is aborted or rescheduled to another host, and in the case
that unshelve fails. In the case of a server build reschedule,
conductor will set the instance.availability_zone appropriately
based on the alternate host for the reschedule. In the other
failure cases, leaving the instance AZ null is appropriate.
Change-Id: I25a4f36027390def83cfe25f4f3b4af9660da502
Closes-Bug: #1790221
|
