commit ad9f37350ad1f4e598a9a5df559b9160db1a11c1
Author: Matt Riedemann <email address hidden>
Date: Thu Mar 7 16:07:18 2019 -0500
Update usage in RT.drop_move_claim during confirm resize
The confirm resize flow in the compute manager
runs on the source host. It calls RT.drop_move_claim
to drop resource usage from the source host for the
old flavor. The problem with drop_move_claim is it
only decrements the old flavor from the reported usage
if the instance is in RT.tracked_migrations, which will
only be there on the source host if the update_available_resource
periodic task runs before the resize is confirmed, otherwise
the instance is still just tracked in RT.tracked_instances on
the source host. This leaves the source compute incorrectly
reporting resource usage for the old flavor until the next
periodic runs, which could be a large window if resizes are
configured to automatically confirm, e.g. resize_confirm_window=1,
and the periodic interval is big, e.g. update_resources_interval=600.
This fixes the issue by also updating usage in drop_move_claim
when the instance is not in tracked_migrations but is in
tracked_instances.
Because of the tight coupling with the instance.migration_context
we need to ensure the migration_context still exists before
drop_move_claim is called during confirm_resize, so a test wrinkle
is added to enforce that.
test_drop_move_claim_on_revert also needed some updating for
reality because of how drop_move_claim is called during
revert_resize.
And finally, the functional recreate test is updated to show the
bug is fixed.
Reviewed: https:/ /review. opendev. org/641806 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=ad9f37350ad 1f4e598a9a5df55 9b9160db1a11c1
Committed: https:/
Submitter: Zuul
Branch: master
commit ad9f37350ad1f4e 598a9a5df559b91 60db1a11c1
Author: Matt Riedemann <email address hidden>
Date: Thu Mar 7 16:07:18 2019 -0500
Update usage in RT.drop_move_claim during confirm resize
The confirm resize flow in the compute manager migrations, which will available_ resource instances on confirm_ window= 1, resources_ interval= 600.
runs on the source host. It calls RT.drop_move_claim
to drop resource usage from the source host for the
old flavor. The problem with drop_move_claim is it
only decrements the old flavor from the reported usage
if the instance is in RT.tracked_
only be there on the source host if the update_
periodic task runs before the resize is confirmed, otherwise
the instance is still just tracked in RT.tracked_
the source host. This leaves the source compute incorrectly
reporting resource usage for the old flavor until the next
periodic runs, which could be a large window if resizes are
configured to automatically confirm, e.g. resize_
and the periodic interval is big, e.g. update_
This fixes the issue by also updating usage in drop_move_claim instances.
when the instance is not in tracked_migrations but is in
tracked_
Because of the tight coupling with the instance. migration_ context
we need to ensure the migration_context still exists before
drop_move_claim is called during confirm_resize, so a test wrinkle
is added to enforce that.
test_ drop_move_ claim_on_ revert also needed some updating for
reality because of how drop_move_claim is called during
revert_resize.
And finally, the functional recreate test is updated to show the
bug is fixed.
Change-Id: Ia6d8a7909081b0 b856bd7e290e234 af7e42a2b38
Closes-Bug: #1818914
Related-Bug: #1641750
Related-Bug: #1498126