libvirt: Fix BlockDevice.wait_for_job when qemu reports no job
We were misinterpreting the return value of blockJobInfo. Most
immediately we were expecting it to return an integer, which has never
been the case. blockJobInfo also raises an exception on error. Note
that the implementation of abort_on_error has always expected an
integer return value, and exceptions have never been handled, which
means that abort_on_error has always been a no-op, and exceptions have
never been swallowed. As this is also the most intuitive behaviour, we
make it explicit by removing abort_on_error. Any exception raised by
blockJobInfo will continue to propagate unhandled.
We were obfuscating the return value indicating that the job did not
exist, {}, by populating a BlockDeviceJobInfo with fake values. We
de-obfuscate this by returning None instead, which is unambiguous.
wait_for_job() was misnamed, as it does not wait. This is renamed to
is_job_complete() to be less confusing. Note that the logic is
reversed.
After discussion with Eric Blake of the libvirt team (see review
comments: https://review.openstack.org/#/c/375652/), we are now
confident asserting that if no job exists then it has completed
(although we are still not sure that it succeeded). Consequently we
remove the wait_for_job_clean parameter, and always assume that no job
means it has completed. Previously this was implicit because no job
meant a defaulted BlockDeviceJobInfo.job value of 0.
Reviewed: https:/ /review. openstack. org/387292 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=a021a72ddae a0e1eb6e3f4b934 870fd5f2a05485
Committed: https:/
Submitter: Jenkins
Branch: stable/newton
commit a021a72ddaea0e1 eb6e3f4b934870f d5f2a05485
Author: Matthew Booth <email address hidden>
Date: Wed Sep 28 16:44:41 2016 +0100
libvirt: Fix BlockDevice. wait_for_ job when qemu reports no job
We were misinterpreting the return value of blockJobInfo. Most
immediately we were expecting it to return an integer, which has never
been the case. blockJobInfo also raises an exception on error. Note
that the implementation of abort_on_error has always expected an
integer return value, and exceptions have never been handled, which
means that abort_on_error has always been a no-op, and exceptions have
never been swallowed. As this is also the most intuitive behaviour, we
make it explicit by removing abort_on_error. Any exception raised by
blockJobInfo will continue to propagate unhandled.
We were obfuscating the return value indicating that the job did not
exist, {}, by populating a BlockDeviceJobInfo with fake values. We
de-obfuscate this by returning None instead, which is unambiguous.
wait_for_job() was misnamed, as it does not wait. This is renamed to job_complete( ) to be less confusing. Note that the logic is
is_
reversed.
After discussion with Eric Blake of the libvirt team (see review /review. openstack. org/#/c/ 375652/), we are now nfo.job value of 0.
comments: https:/
confident asserting that if no job exists then it has completed
(although we are still not sure that it succeeded). Consequently we
remove the wait_for_job_clean parameter, and always assume that no job
means it has completed. Previously this was implicit because no job
meant a defaulted BlockDeviceJobI
Co-authored-by: Sławek Kapłoński <email address hidden> a60412ad7a374ee 38cebdeb579 e49f2d30ca79be9 6298217b7e)
Closes-Bug: #1627134
Change-Id: I2d0daa32b1d37f
(cherry picked from commit 0f4bd241665c287