23 Feb
2022
23 Feb
'22
3:43 p.m.
Branch: refs/heads/master
Home: https://github.com/tribe29/checkmk
Commit: e06beff083fa7df208caca91db2aff9802936e56
https://github.com/tribe29/checkmk/commit/e06beff083fa7df208caca91db2aff980…
Author: Mathias Laurin <mathias.laurin(a)tribe29.com>
Date: 2022-02-23 (Wed, 23 Feb 2022)
Changed paths:
M cmk/utils/type_defs/pluginname.py
M tests/unit/cmk/utils/test_type_defs_plugin_name.py
Log Message:
-----------
Do not call instance methods from __init__
It is not correct to call instance methods from `__init__()` because
they take `self` as their first argument but `self` is not initialized
until after `__init__` is finished.
This can result in strange error messages such as:
self = <[AttributeError("'SectionName' object has no attribute
'_value'")
raised in repr()] SectionName object at 0x7f760dd276d0>
What we *can* do instead is calling class methods. Now, instead of
calling class methods with `type(self)` in `__init__`, the more proper
way is to validate the arguments in `__new__` and keep `__init__` as
simple as possible.
Furthermore, we can see from the code that this is what was expected as
`_parse_valid()` (now `_validate_args()`) was always acting on
`self.__class__` and never on `self` and `self.__class__`, or
`type(class)` *is* `cls` in a class method.
Change-Id: I8ad0d717fb96719de075d808e0383b19d4782525
Commit: 9a049416906a9eaeb2ea8dceded27f6c05636f63
https://github.com/tribe29/checkmk/commit/9a049416906a9eaeb2ea8dceded27f6c0…
Author: Mathias Laurin <mathias.laurin(a)tribe29.com>
Date: 2022-02-23 (Wed, 23 Feb 2022)
Changed paths:
M cmk/utils/type_defs/pluginname.py
Log Message:
-----------
Definition of __hash__() mandates immutability
Make both attributes explicitly immutable in a class that defines
`__hash__()` where it is an implicit requirement.
Change-Id: If428ddd7b7830092f126b6399ab46d7ffb7ed205
Commit: 755fdaabeec7133e7beae520d2a53a3fdde07fc8
https://github.com/tribe29/checkmk/commit/755fdaabeec7133e7beae520d2a53a3fd…
Author: Mathias Laurin <mathias.laurin(a)tribe29.com>
Date: 2022-02-23 (Wed, 23 Feb 2022)
Changed paths:
M cmk/utils/type_defs/pluginname.py
Log Message:
-----------
Make abstract class... abstract
Change-Id: I984180ad02bd0e5e67c6b084a6ba377222deb45c
Commit: 6f413142aaef25e92491c7920ad341933248082b
https://github.com/tribe29/checkmk/commit/6f413142aaef25e92491c7920ad341933…
Author: Lars Michelsen <lm(a)tribe29.com>
Date: 2022-02-23 (Wed, 23 Feb 2022)
Changed paths:
A .werks/13636
M omd/Makefile
M omd/distros/SLES_12SP3.mk
M omd/distros/SLES_12SP4.mk
M omd/distros/SLES_12SP5.mk
M omd/distros/SLES_15.mk
M omd/distros/SLES_15SP1.mk
M omd/distros/SLES_15SP2.mk
M omd/distros/SLES_15SP3.mk
M omd/packages/omd/skel/etc/init.d/xinetd
M omd/packages/packages.make
A omd/packages/xinetd/xinetd-2.3.15.4.tar.xz
A omd/packages/xinetd/xinetd.make
Log Message:
-----------
13636 FIX Fix xinetd installation problem on SLES15
When trying to install Checkmk on SLES15 this failed, because the package
dependency 'xinetd' could not be provided by the official package repositories.
It is not possible to get xinetd from official SLES package repositories,
because it has been dropped in favour of systemd.
The switch to systemd is possible, if you can register regular services to the
systemd unit system and let systemd manage your units. But in our case, where
we have an xinetd process that is managed as part of an OMD site, this way will
not work.
Users were able to solve the situation locally by installing xinetd from 3rd
party sources, like for example OpenSUSE.org repositories. However, this
approach is not supported by SLES nor straight forward for users.
To make the installation more straight forward again, we now drop the xinetd
package dependency for all supported SLES distributions from our Checkmk
packages and ship xinetd together with Checkmk.
CMK-9441
Change-Id: Ie94ab5e4d7ae5ef07cbb85af176907bbf6b67614
Compare: https://github.com/tribe29/checkmk/compare/2b048b184a71...6f413142aaef