Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
S
snf-ganeti
Manage
Activity
Members
Labels
Plan
Issues
0
Issue boards
Milestones
Wiki
Code
Merge requests
0
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
itminedu
snf-ganeti
Commits
0f933d15
Commit
0f933d15
authored
16 years ago
by
Guido Trotter
Browse files
Options
Downloads
Patches
Plain Diff
Add doc/locking.txt, documenting locking order
Reviewed-by: imsnah
parent
082c5adb
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
Makefile.am
+1
-0
1 addition, 0 deletions
Makefile.am
doc/locking.txt
+33
-0
33 additions, 0 deletions
doc/locking.txt
with
34 additions
and
0 deletions
Makefile.am
+
1
−
0
View file @
0f933d15
...
...
@@ -139,6 +139,7 @@ EXTRA_DIST = \
doc/examples/ganeti.initd.in
\
doc/examples/ganeti.cron.in
\
doc/examples/dumb-allocator
\
doc/locking.txt
\
test
/testutils.py
\
test
/mocks.py
\
$(
dist_TESTS
)
\
...
...
This diff is collapsed.
Click to expand it.
doc/locking.txt
0 → 100644
+
33
−
0
View file @
0f933d15
Introduction:
This document describes lock order dependencies in Ganeti.
It is divided by functional sections
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
(locking.py). They are acquired in the following order:
* BGL: this is the Big Ganeti Lock, it exists for retrocompatibility. New LUs
acquire it in a shared fashion, and are able to execute all toghether
(baring other lock waits) while old LUs acquire it exclusively and can only
execute one at a time, and not at the same time with new LUs.
* Instance locks: can be declared in ExpandNames() o DeclareLocks() by an LU,
and have the same name as the instance itself. They are acquired as a set.
Internally the locking library acquired them in alphabetical order.
* Node locks: can be declared in ExpandNames() o DeclareLocks() by an LU, and
have the same name as the node itself. They are acquired as a set.
Internally the locking library acquired them in alphabetical order. Given
this order it's possible to safely acquire a set of instances, and then the
nodes they reside on.
The ConfigWriter (in config.py) is also protected by a SharedLock, which is
shared by functions that read the config and acquired exclusively by functions
that modify it. Since the ConfigWriter calls rpc.call_upload_file to all nodes
to distribute the config without holding the node locks, this call must be able
to execute on the nodes in parallel with other operations (but not necessarily
concurrently with itself on the same file, as inside the ConfigWriter this is
called with the internal config lock held.
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment