3a0f26c822
When an instance with attached volumes fails to spawn, cleanup code within the compute manager (_shutdown_instance called from _build_resources) will delete the volume attachments referenced by the bdms in Cinder. As a result we should check and if necessary recreate these volume attachments when rescheduling an instance. Note that there are a few different ways to fix this bug by making changes to the compute manager code, either by not deleting the volume attachment on failure before rescheduling [1] or by performing the get/create check during each build after the reschedule [2]. The problem with *not* cleaning up the attachments is if we don't reschedule, then we've left orphaned "reserved" volumes in Cinder (or we have to add special logic to tell compute when to cleanup attachments). The problem with checking the existence of the attachment on every new host we build on is that we'd be needlessly checking that for initial creates even if we don't ever need to reschedule, unless again we have special logic against that (like checking to see if we've rescheduled at all). Also, in either case that involves changes to the compute means that older computes might not have the fix. So ultimately it seems that the best way to handle this is: 1. Only deal with this on reschedules. 2. Let the cell conductor orchestrate it since it's already dealing with the reschedule. Then the compute logic doesn't need to change. [1] https://review.openstack.org/#/c/587071/3/nova/compute/manager.py@1631 [2] https://review.openstack.org/#/c/587071/4/nova/compute/manager.py@1667 Conflicts: nova/tests/unit/conductor/test_conductor.py NOTE(mriedem): There was a minor conflict due to not having change I56fb1fd984f06a58c3a7e8c2596471991950433a in Queens. Change-Id: I739c06bd02336bf720cddacb21f48e7857378487 Closes-bug: #1784353 (cherry picked from commit |
||
---|---|---|
.. | ||
README.rst | ||
__init__.py | ||
test_bug_1404867.py | ||
test_bug_1522536.py | ||
test_bug_1541691.py | ||
test_bug_1548980.py | ||
test_bug_1552888.py | ||
test_bug_1554631.py | ||
test_bug_1558866.py | ||
test_bug_1568208.py | ||
test_bug_1595962.py | ||
test_bug_1620248.py | ||
test_bug_1627838.py | ||
test_bug_1670627.py | ||
test_bug_1671648.py | ||
test_bug_1675570.py | ||
test_bug_1678326.py | ||
test_bug_1679750.py | ||
test_bug_1682693.py | ||
test_bug_1689692.py | ||
test_bug_1702454.py | ||
test_bug_1713783.py | ||
test_bug_1718455.py | ||
test_bug_1718512.py | ||
test_bug_1719730.py | ||
test_bug_1732947.py | ||
test_bug_1735407.py | ||
test_bug_1741125.py | ||
test_bug_1741307.py | ||
test_bug_1746483.py | ||
test_bug_1746509.py | ||
test_bug_1780373.py | ||
test_bug_1784353.py |
README.rst
Tests for Specific Regressions
When we have a bug reported by end users that we can write a full stack reproduce on, we should. And we should keep a regression test for that bug in our tree. It can be deleted at some future date if needed, but largely should not be changed.
Writing Regression Tests
- These should be full stack tests which inherit from nova.test.TestCase directly. (This is to prevent coupling with other tests).
- They should setup a full stack cloud in their setUp via fixtures
- They should each live in a file which is named test_bug######.py
Writing Tests Before the Bug is Fixed
TODO describe writing and landing tests before the bug is fixed as a reproduce.