-Introduction:
+Ganeti locking
+==============
+
+Introduction
+------------
This document describes lock order dependencies in Ganeti.
It is divided by functional sections
-Opcode Execution Locking:
+Opcode Execution Locking
+------------------------
These locks are declared by Logical Units (LUs) (in cmdlib.py) and acquired by
the Processor (in mcpu.py) with the aid of the Ganeti Locking Library
concurrently with itself on the same file, as inside the ConfigWriter this is
called with the internal config lock held.
+
+Job Queue Locking
+-----------------
+
+The job queue is designed to be thread-safe. This means that its public
+functions can be called from any thread. The job queue can be called from
+functions called by the queue itself (e.g. logical units), but special
+attention must be paid not to create deadlocks or an invalid state.
+
+The single queue lock is used from all classes involved in the queue handling.
+During development we tried to split locks, but deemed it to be too dangerous
+and difficult at the time. Job queue functions acquiring the lock can be safely
+called from all the rest of the code, as the lock is released before leaving
+the job queue again. Unlocked functions should only be called from job queue
+related classes (e.g. in jqueue.py) and the lock must be acquired beforehand.
+
+In the job queue worker (``_JobQueueWorker``), the lock must be released before
+calling the LU processor. Otherwise a deadlock can occur when log messages are
+added to opcode results.
+
+
+Node Daemon Locking
+-------------------
+
+The node daemon contains a lock for the job queue. In order to avoid conflicts
+and/or corruption when an eventual master daemon or another node daemon is
+running, it must be held for all job queue operations
+
+There's one special case for the node daemon running on the master node. If
+grabbing the lock in exclusive fails on startup, the code assumes all checks
+have been done by the process keeping the lock.
projects / ganeti-local / blobdiff