tempest plugin can deadlock on test_delete_introspection
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ironic |
Fix Released
|
Medium
|
Unassigned |
Bug Description
The ironic-
Which is fine if your only creating API records.
But... creating an allocation launches a worker task[1], and also immediately returns back to the caller with the base allocation.
Under the hood, the allocation attempts to identify candidates, and then allocate a node. The act of allocating a node holds a lock on the node, and in that entire process, calls allocation.save().
Allocation.save() internally, on the object calls update_
Anyhow, this row will occur locked multiple times, and has the deadlock decorator on it today. Except going and trying to delete the row in a new transaction can cause issues to begin with.
The allocation is only safe to delete, realistically when it's state is in ERROR or ACTIVE. In flight might conflict.
So a few things are broken here:
1) The tempest plugin is just a tad bit too aggressive.
2) The update_allocation db_api call should re-query with a read and hand that back instead of the row from the writer transaction. While it flushes, it is still an open writer.
3) We *likely* need constrain the ability to delete an allocation that is still in flight.
[0]: https:/
[1]: https:/
[2]: https:/
Changed in ironic: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in ironic: | |
status: | Confirmed → Fix Released |
This issue was fixed in the openstack/ironic 22.1.0 release.