j3d1/webvirtcloud
1
0
Fork 0
mirror of https://github.com/retspen/webvirtcloud synced 2026-11-10 20:26:48 +00:00
Code Issues Projects Releases Wiki Activity

fix(computes): a VM moved between computes keeps its owners on PostgreSQL

Browse source 
Two computes decide the owners of the same UUID: the one the VM left
buries them in a tombstone (or a compute delete does), the one it went
to restores them. On PostgreSQL the two ran at once: the restore still
saw the old row of the uncommitted bury, skipped, and the VM ended up
without owners while the tombstone stayed. SQLite was never affected:
its IMMEDIATE transactions take the write lock at the start.

The reconcile and the compute delete now take one transaction-level
advisory lock (pg_advisory_xact_lock) when their database step starts,
so ownership decisions run one after another on PostgreSQL as they do
on SQLite. Reading libvirt stays outside the lock.
This commit is contained in:
catborise 2026-10-23 15:07:45 +03:00
parent 291690bb20
commit addc7ccfcb
3 changed files with 99 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

3
computes/models.py
View file

@ -96,9 +96,10 @@ class Compute(Model):
exclusive, so no reconcile, VM operation or job on it runs meanwhile
(Busy if one does); its row is locked before its VMs', as the
reconcile does."""
from computes.utils import forget, libvirt_compute_lock
from computes.utils import forget, libvirt_compute_lock, lock_ownership
with libvirt_compute_lock(self), transaction.atomic():
lock_ownership()
Compute.objects.select_for_update().filter(pk=self.pk).first()
for inst in self.instance_set.select_for_update():
forget(inst)