docs: fix lock file deadlock documentation for dynamic plugins cache#5026
docs: fix lock file deadlock documentation for dynamic plugins cache#5026Fortune-Ndlovu wants to merge 3 commits into
Conversation
- Fix wrong lock file name in rm command (RHDHBUGS-450) - Document 10-min timeout and CrashLoopBackOff behavior - Add DYNAMIC_PLUGINS_LOCK_TIMEOUT_MS env var - Clarify lock only applies with persistent volumes
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5026 +/- ##
==========================================
- Coverage 55.39% 54.77% -0.62%
==========================================
Files 122 110 -12
Lines 2365 2147 -218
Branches 562 538 -24
==========================================
- Hits 1310 1176 -134
+ Misses 1048 969 -79
+ Partials 7 2 -5
Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
Remove incorrect CrashLoopBackOff claim. The exit handler auto-cleans the stale lock on shutdown so the pod self-heals after one timeout cycle. Reframe manual rm as optional shortcut. Add note that 1.10.x and earlier had no timeout (Python script, infinite wait). Signed-off-by: Fortune Ndlovu <fndlovu@redhat.com>
|
The container image build workflow finished with status: |
|
| The directory where dynamic plugins are located is mounted as a volume to the `install-dynamic-plugins` init container and the `backstage-backend` container. The `install-dynamic-plugins` init container is responsible for downloading and extracting the plugins into this directory. Depending on the deployment method, the directory is mounted as an ephemeral or persistent volume. In the latter case, the volume can be shared between several Pods, and the plugins installation script is also responsible for downloading and extracting the plugins only once, avoiding conflicts. | ||
|
|
||
| **Important Note:** If `install-dynamic-plugins` init container was killed with SIGKILL signal, which may happen due to the following reasons: | ||
| **Important Note:** When the `dynamic-plugins-root` directory is backed by a persistent volume, the `install-dynamic-plugins` init container uses a lock file (`/dynamic-plugins-root/install-dynamic-plugins.lock`) to prevent concurrent plugin installations across Pods that share the same volume. The lock is acquired before installation begins and released when it completes (or fails). |
There was a problem hiding this comment.
When the
dynamic-plugins-rootdirectory is backed by a persistent volume, theinstall-dynamic-pluginsinit container uses a lock file
Might be a bit misleading, as the lock file is always checked/created when the install-dynamic-plugins init container starts, regardless of the volume type. Only the contention scenario (another pod holding the lock or a pod that was SIGKILL'ed and reusing the volume) requires a persistent volume.
2 participants
Summary
dynamic-plugins.lock→install-dynamic-plugins.lock, matching types.ts#L78)DYNAMIC_PLUGINS_LOCK_TIMEOUT_MSenvironment variable documentationRelates-to: RHDHBUGS-450
Test plan
install-dynamic-plugins.lock)