commit 89b6da0c2832e739e6e0d30a0e205165005dc41c
Author: Matt Riedemann <email address hidden>
Date: Thu Jun 15 11:46:44 2017 -0400
Provide original fault message when BFV fails
When booting from volume and Nova is creating the volume,
it can fail (timeout, invalid AZ in Cinder, etc) and the
generic Exception handling in _prep_block_device will log
the original exception trace but then raise a generic
InvalidBDM exception, which is handled higher up and converted
to a BuildAbortException, which is recorded as an instance
fault, but the original error message is lost from the fault.
It would be better to include the original exception message that
triggered the failure so that goes into the fault for debug.
For example, this is a difference of getting an error like this:
BuildAbortException: Build of instance
9484f5a7-3198-47ff-b728-178515a26277 aborted:
Block Device Mapping is Invalid.
To something more useful like this:
BuildAbortException: Build of instance
9484f5a7-3198-47ff-b728-178515a26277 aborted:
Volume da947c97-66c6-4b7e-9ae6-54eb8128bb75 did not finish
being created even after we waited 3 seconds or 2 attempts.
And its status is error.
Change-Id: I20a5e8e5e10dd505c1b24c208f919c6550e9d1a4
Closes-Bug: #1693315
(cherry picked from commit 20c4715a49a44c642882618f102cd0fc9342978d)
(cherry picked from commit 0d5fd4356af38ca0487979ad614d294a2002911d)
Reviewed: https:/ /review. openstack. org/493206 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=89b6da0c283 2e739e6e0d30a0e 205165005dc41c
Committed: https:/
Submitter: Zuul
Branch: stable/newton
commit 89b6da0c2832e73 9e6e0d30a0e2051 65005dc41c
Author: Matt Riedemann <email address hidden>
Date: Thu Jun 15 11:46:44 2017 -0400
Provide original fault message when BFV fails
When booting from volume and Nova is creating the volume, tion, which is recorded as an instance
it can fail (timeout, invalid AZ in Cinder, etc) and the
generic Exception handling in _prep_block_device will log
the original exception trace but then raise a generic
InvalidBDM exception, which is handled higher up and converted
to a BuildAbortExcep
fault, but the original error message is lost from the fault.
It would be better to include the original exception message that
triggered the failure so that goes into the fault for debug.
For example, this is a difference of getting an error like this:
BuildAbor tException: Build of instance 3198-47ff- b728-178515a262 77 aborted:
9484f5a7-
Block Device Mapping is Invalid.
To something more useful like this:
BuildAbor tException: Build of instance 3198-47ff- b728-178515a262 77 aborted: 66c6-4b7e- 9ae6-54eb8128bb 75 did not finish
9484f5a7-
Volume da947c97-
being created even after we waited 3 seconds or 2 attempts.
And its status is error.
Change-Id: I20a5e8e5e10dd5 05c1b24c208f919 c6550e9d1a4 42882618f102cd0 fc9342978d) 0487979ad614d29 4a2002911d)
Closes-Bug: #1693315
(cherry picked from commit 20c4715a49a44c6
(cherry picked from commit 0d5fd4356af38ca