commit 1342cd75e9a091d28bec857f44f833ab5a7d1b96
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/648410 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=1342cd75e9a 091d28bec857f44 f833ab5a7d1b96
Committed: https:/
Submitter: Zuul
Branch: stable/rocky
commit 1342cd75e9a091d 28bec857f44f833 ab5a7d1b96
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.
Conflicts:
nova/ compute/ api.py
nova/ tests/unit/ compute/ test_compute_ api.py
NOTE(mriedem): The conflict is due to not having change 18059b55f90e812 b57f1e11d566c6f in Rocky.
I34ffaf2857
Change-Id: I8dc862b90d398b 693b259abd35836 16d07d8d206 63f4c7e27ede7b5 9a1d63c14a) b627aa247c45b0b 19393466c0)
Closes-Bug: #1819963
(cherry picked from commit 40f6672f53794b5
(cherry picked from commit 26e59912838b145