Revision fe78783d doc/design-daemons.rst
b/doc/design-daemons.rst | ||
---|---|---|
439 | 439 |
provided for convenience, it's redundant wrt. *list* and *update*. Immediate, |
440 | 440 |
never fails. |
441 | 441 |
|
442 |
Addidional restrictions due to lock implications: |
|
443 |
Ganeti supports locks that act as if a lock on a whole group (like all nodes) |
|
444 |
were held. To avoid dead locks caused by the additional blockage of those |
|
445 |
group locks, we impose certain restrictions. Whenever `A` is a group lock and |
|
446 |
`B` belongs to `A`, then the following holds. |
|
447 |
|
|
448 |
- `A` is in lock order before `B`. |
|
449 |
- All locks that are in the lock order between `A` and `B` also belong to `A`. |
|
450 |
- It is considered a lock-order violation to ask for an exclusive lock on `B` |
|
451 |
while holding a shared lock on `A`. |
|
452 |
|
|
442 | 453 |
After this step it'll be possible to use locks from jobs as separate processes. |
443 | 454 |
|
444 | 455 |
The above set of operations allows the clients to use various work-flows. In particular: |
Also available in: Unified diff