Comment 12 for bug 1882804
Revision history for this message
| Bence Romsics (bence-romsics) wrote | #12 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Yep, I believe we have to accept that some inconsistency will happen occasionally (due to the distributed and non-transactional nature of the neutron-placement system) and we have to choose which side we want to fail on: over- or underallocation. In previous cases around the base feature I believe we chose to occasionally fail by overallocation (therefore wasting some resource but still able to provide guarantees).
It seems to me the cleanup after the overallocation is simple: delete the instance.
Also consider which failure is more likely:
1) neutron db transaction succeeds but the placement transaction after is interrupted
2) the reverse order
My hunch is that (1) is more likely therefore (2) is a better choice (unless we choose (1) AND start tracking the status of the placement transaction).