Changes to instance.system_metadata weren't properly being saved
to the DB. The change to 'network_allocated' would be written to
the DB but not updated on the instance object. When the network
was cleaned up before a reschedule, the object would not notice
network_allocated' getting set to False, and not write the change
to the DB. After the reschedule, the instance would still have
'network_allocated' set to True, and skip allocating a network.
The node would go active with no network.
Since this is happening in the _allocate_network_async greenthread,
the solution is not to save in the async thread. The main thread
and the async thread share a reference to the same object and the
main thread waits for the async thread to finish before the final
save, so saving is unnecessary. I added comments on the
instance.save() calls that were part of the race so they don't get
removed or changed and reintroduce this bug.
Also, update the relevant test from mox to mock.
Closes-Bug: #1460176
Change-Id: I937ec020b46703392bd603008d03af0f422bc0d1
(cherry picked from commit 717aa88f14e549d9e5d8b252ba7128e3dac991b6)
Reviewed: https:/ /review. openstack. org/186873 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=c42b47ef1ae fcd84be8867ea63 d5ff25c7d2a734
Committed: https:/
Submitter: Jenkins
Branch: stable/kilo
commit c42b47ef1aefcd8 4be8867ea63d5ff 25c7d2a734
Author: Josh Gachnang <email address hidden>
Date: Fri Apr 24 14:31:26 2015 -0700
Reschedules sometimes do not allocate networks
Changes to instance. system_ metadata weren't properly being saved allocated' getting set to False, and not write the change allocated' set to True, and skip allocating a network.
to the DB. The change to 'network_allocated' would be written to
the DB but not updated on the instance object. When the network
was cleaned up before a reschedule, the object would not notice
network_
to the DB. After the reschedule, the instance would still have
'network_
The node would go active with no network.
Since this is happening in the _allocate_ network_ async greenthread,
the solution is not to save in the async thread. The main thread
and the async thread share a reference to the same object and the
main thread waits for the async thread to finish before the final
save, so saving is unnecessary. I added comments on the
instance.save() calls that were part of the race so they don't get
removed or changed and reintroduce this bug.
Also, update the relevant test from mox to mock.
Closes-Bug: #1460176
Change-Id: I937ec020b46703 392bd603008d03a f0f422bc0d1 9e5d8b252ba7128 e3dac991b6)
(cherry picked from commit 717aa88f14e549d