Branch: refs/heads/master
Home:
https://github.com/tribe29/checkmk
Commit: 276ce4d3dc58628a09b8e3f58d5dce4ffd483e19
https://github.com/tribe29/checkmk/commit/276ce4d3dc58628a09b8e3f58d5dce4ff…
Author: Lars Michelsen <lm(a)tribe29.com>
Date: 2020-09-11 (Fri, 11 Sep 2020)
Changed paths:
A .werks/11490
M cmk/base/core.py
M cmk/base/core_config.py
M cmk/base/core_nagios.py
M cmk/base/modes/check_mk.py
M tests/integration/cmk/base/test_modes.py
Log Message:
-----------
11490 Remove cmk -B and cmk -C commands
During the activation of configuration changes we have multiple subsequent steps:
LI: Acquire the activation lock
LI: Create the core config (incl. backup and restore in case of issues)
LI: Precompile some more files for the core
LI: Restart of the core or reload of the config
The most common commands to execute the activation or parts of the procedure
are "cmk -U" for just creating the configuration or "cmk -O" for
creating the
configuration and reloading the core config and "cmk -R" for creating the
configuration and restarting the core process.
The commands "cmk -B" (Create core config) and "cmk -C" (precompile
some files)
were providing direkt access to parts of the "cmk -U" command but rarely used.
To simplify things we are now dropping both, the "cmk -B" and "cmk
-C"
commands. If you used one of these before, please use "cmk -U" in the future.
Change-Id: I9e2a829a2466f9ec8bdc845eafa33992a726a51e
Commit: 98f900b081900c97feb5caf1a38eff8521f6f86c
https://github.com/tribe29/checkmk/commit/98f900b081900c97feb5caf1a38eff852…
Author: Lars Michelsen <lm(a)tribe29.com>
Date: 2020-09-11 (Fri, 11 Sep 2020)
Changed paths:
M cmk/base/core.py
M cmk/base/core_config.py
M cmk/base/modes/check_mk.py
Log Message:
-----------
Consolidate monitoring config creation
We now have two scenarios left:
a) cmk -U: Create the core config
b) cmk -O / cmk -R: Create the core config + reload or restart of the core
Both call paths are now using the `do_create_config` function for
"create the core config" step and both are now also using the same
logic for backing up and restoring the objects file which was missing
with "cmk -U" before.
Another remaining difference is that cmk -U does not respect the
activation lock. This will be streamlined in the next commit.
Change-Id: I16a7b2394ac6375c06ac570436bfd99e0f42dff2
Commit: 098f49182a5bf8b2aafa1974e660b71cd3ad091d
https://github.com/tribe29/checkmk/commit/098f49182a5bf8b2aafa1974e660b71cd…
Author: Lars Michelsen <lm(a)tribe29.com>
Date: 2020-09-11 (Fri, 11 Sep 2020)
Changed paths:
M cmk/utils/store.py
M tests/unit/cmk/utils/test_store.py
Log Message:
-----------
Add context manager for non blocking locks
Along the way:
* Cleanup the existing blocking lock test
* Add test for non blocking file locking
* Add tests and move some initialization to common fixture locked_file.
Change-Id: I3124cd0e7e4ffc4e439813781561edd45a15a46e
Commit: 58821bdca77b9c695df8afcb4792ba6dc282367e
https://github.com/tribe29/checkmk/commit/58821bdca77b9c695df8afcb4792ba6dc…
Author: Lars Michelsen <lm(a)tribe29.com>
Date: 2020-09-11 (Fri, 11 Sep 2020)
Changed paths:
M cmk/base/core.py
Log Message:
-----------
Activation lock: Refactor to context manager; use common locking logic
Change-Id: Ie008e103abbcd9332c27f3474b37fab17cf3c748
Commit: 256e347cb8f6cf6dfbdea8c36da28a3a83023d87
https://github.com/tribe29/checkmk/commit/256e347cb8f6cf6dfbdea8c36da28a3a8…
Author: Lars Michelsen <lm(a)tribe29.com>
Date: 2020-09-11 (Fri, 11 Sep 2020)
Changed paths:
M cmk/base/modes/check_mk.py
Log Message:
-----------
Also use activation lock for config creation only
The lock is acquired by "create config + reload/restart" and is expected
to lock a) the core config creation and b) core process restarts.
Since "cmk -U" is doing the "create config" step, it also has to
respect
the same lock.
Change-Id: I4cabe445d6818b7e20311f9bbadc0cc84a2bb978
Compare:
https://github.com/tribe29/checkmk/compare/342ae7754473...256e347cb8f6