-
Bug
-
Resolution: Done
-
Minor
-
1.3.5, 1.4.2, 1.5.0
-
None
-
1
-
False
-
-
False
-
-
-
RHDH Install 3270
Description of problem:
Follow-up to RHDHBUGS-135:
It would be helpful for operators if in addition to Waiting for lock release..., the waitloop process communicated where the lockfile was located on disk so that ops teams can use the output from RHDH on its own rather than having to refer to the lock breaking documentation. It's an odd asymmetry in log output, since the locking mechanism communicates where it creates the lockfile (Created lock file: /dynamic-plugins-root/install-dynamic-plugins.lock).
Prerequisites (if any, like setup, operators/versions):
RHDH >= 1.3.5
Steps to Reproduce
- <steps>
Actual results:
The install-dynamic-plugins init container currently prints: "======= Waiting for lock release..." when it is waiting for the lock file to be released.
Expected results:
It should also print the absolute path of the lockfile it is waiting for, so that users can know which file they need to handle in case a manual intervention is needed.
It already does this when creating and releasing the lockfile, but not when waiting for it, e.g.:
======= Created lock file: /dynamic-plugins-root/install-dynamic-plugins.lock [...] ======= Removed lock file: /dynamic-plugins-root/install-dynamic-plugins.lock
Reproducibility (Always/Intermittent/Only Once):
Always
Build Details:
Additional info (Such as Logs, Screenshots, etc):
- is caused by
-
RHIDP-5833 Manage concurrent writing on install dynamic plugins
-
- Closed
-
-
RHIDP-5732 Manage concurrent writing on install dynamic plugins
-
- Closed
-
-
RHIDP-5834 Manage concurrent writing when installing dynamic plugins
-
- Closed
-
- links to