commit 40f6672f53794b563f4c7e27ede7b59a1d63c14a
Author: Matt Riedemann <email address hidden>
Date: Wed Mar 13 16:20:47 2019 -0400
Update instance.availability_zone on revertResize
When resizing a server that was not created in an explicit
zone, the scheduler can pick a host in another zone and
conductor will update the instance.availability_zone value
for the new dest host zone.
The problem is when reverting the resize, the server goes
back to the original source host/zone but the
instance.availability_zone value in the database is not
updated which can lead to incorrect results when listing
servers and filtering by zone.
This fixes the bug by updating the instance.availability_zone
value in the API (where we have access to the aggregates
table in the API DB) before casting to nova-compute to
complete the revert. As noted in the comment within, this
is not fail-safe in case the revert fails before the
instance.host is updated in finish_revert_resize, but we
don't have a lot of great backportable options here that
don't involve "up-calls" from the compute to the API DB.
Reviewed: https:/ /review. openstack. org/643155 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=40f6672f537 94b563f4c7e27ed e7b59a1d63c14a
Committed: https:/
Submitter: Zuul
Branch: master
commit 40f6672f53794b5 63f4c7e27ede7b5 9a1d63c14a
Author: Matt Riedemann <email address hidden>
Date: Wed Mar 13 16:20:47 2019 -0400
Update instance. availability_ zone on revertResize
When resizing a server that was not created in an explicit availability_ zone value
zone, the scheduler can pick a host in another zone and
conductor will update the instance.
for the new dest host zone.
The problem is when reverting the resize, the server goes availability_ zone value in the database is not
back to the original source host/zone but the
instance.
updated which can lead to incorrect results when listing
servers and filtering by zone.
This fixes the bug by updating the instance. availability_ zone revert_ resize, but we
value in the API (where we have access to the aggregates
table in the API DB) before casting to nova-compute to
complete the revert. As noted in the comment within, this
is not fail-safe in case the revert fails before the
instance.host is updated in finish_
don't have a lot of great backportable options here that
don't involve "up-calls" from the compute to the API DB.
Change-Id: I8dc862b90d398b 693b259abd35836 16d07d8d206
Closes-Bug: #1819963