During a resize, the RequestSpec.flavor is updated
to the new flavor. If the resize failed on one host
and was rescheduled, the RequestSpec.retry is updated
for that failed host and mistakenly persisted, which
can affect later move operations, like if an admin
targets one of those previously failed hosts for a
live migration or evacuate operation.
This change fixes the problem by not ever persisting
the RequestSpec.retry field to the database, since
retries are per-request/operation and not something
that needs to be persisted.
Alternative to this, we could reset the retry field
in the RequestSpec.reset_forced_destinations method
but that would be slightly overloading the meaning
of that method, and the approach taken in this patch
is arguably cleaner since retries shouldn't ever be
persisted. It should be noted, however, that one
advantage to resetting the 'retry' field in the
RequestSpec.reset_forced_destinations method would
be to avoid this issue for any existing DB entries
that have this problem.
The related functional regression test is updated
to show the bug is now fixed.
Reviewed: https:/ /review. openstack. org/559447 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=6647f11dc1a ba89f9b0e2703f2 36a43f31d88079
Committed: https:/
Submitter: Zuul
Branch: master
commit 6647f11dc1aba89 f9b0e2703f236a4 3f31d88079
Author: Matt Riedemann <email address hidden>
Date: Fri Apr 6 20:28:53 2018 -0400
Don't persist RequestSpec.retry
During a resize, the RequestSpec.flavor is updated
to the new flavor. If the resize failed on one host
and was rescheduled, the RequestSpec.retry is updated
for that failed host and mistakenly persisted, which
can affect later move operations, like if an admin
targets one of those previously failed hosts for a
live migration or evacuate operation.
This change fixes the problem by not ever persisting operation and not something
the RequestSpec.retry field to the database, since
retries are per-request/
that needs to be persisted.
Alternative to this, we could reset the retry field reset_forced_ destinations method .reset_ forced_ destinations method would
in the RequestSpec.
but that would be slightly overloading the meaning
of that method, and the approach taken in this patch
is arguably cleaner since retries shouldn't ever be
persisted. It should be noted, however, that one
advantage to resetting the 'retry' field in the
RequestSpec
be to avoid this issue for any existing DB entries
that have this problem.
The related functional regression test is updated
to show the bug is now fixed.
Change-Id: Iadbf8ec935565a 6d4ccf6f36ef630 ab6bf1bea5d
Closes-Bug: #1718512