Possible regression after update to 2.4.0p30: use_new_descriptions_for expected as dict but distributed site still has list

Troubleshooting
,
1

CMK version: 2.4.0p19cre
OS version: openSUSE 15.6

Output of “cmk --debug -vvn hostname”:

File “/omd/sites/mkfope/lib/python3/cmk/base/config.py”, line 1253, in _get_service_description_template_and_item
if old_descr is None or use_new_descriptions_for.get(plugin_name_str, False):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: ‘list’ object has no attribute ‘get’

Hi all,

after updating one of our Checkmk sites from 2.4.0p19.cre to 2.4.0p30.cre, I am no longer able to activate the site configuration or perform a rescan/discovery on affected hosts.

The site is a remote site in a distributed monitoring setup.

Environment

  • Checkmk edition: CRE / Community

  • Previous version: 2.4.0p19.cre

  • Updated version: 2.4.0p30.cre

  • Site type: remote site

  • Setup: distributed monitoring

  • Core type: Nagios

After the update to 2.4.0p30.cre, running:

cmk --debug -vvU

fails with:

Configuration Error: 'list' object has no attribute 'get'

Full traceback points to:

File "/omd/sites/mkfope/lib/python3/cmk/base/config.py", line 1253, in _get_service_description_template_and_item

    if old_descr is None or use_new_descriptions_for.get(plugin_name_str, False):

                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

AttributeError: 'list' object has no attribute 'get'

The same error also happens when dumping host configuration / doing rescan-related operations, for example:

cmk -vvD hostname
cmk --debug -vvn hostname

The issue seems related to the global setting use_new_descriptions_for .
In 2.4.0p30, the code appears to expect this variable to be a dictionary, because it calls:

use_new_descriptions_for.get(plugin_name_str, False)

However, on the upgraded distributed remote site, the variable is still present as a list.

I have screenshots showing the following behavior:

  1. Checkmk 2.4.0p19
    use_new_descriptions_for is stored as a list.

    image

  2. Checkmk 2.4.0p30 distributed/remote site after update
    use_new_descriptions_for is still stored as a list.

    image

  3. Checkmk 2.4.0p30 fresh site
    use_new_descriptions_for is stored as a dict.

    image

  4. Checkmk 2.5.0p4 fresh site
    use_new_descriptions_for is stored as a dict.

    image
    image1438×118 59.9 KB

This suggests that the fresh-site default/config schema has changed to dictionary format, but the upgraded distributed site may not have migrated this value correctly, or the remote site receives/keeps an older representation from the central/distributed configuration.

Is this a known regression or migration issue in 2.4.0p30.cre, especially in distributed monitoring setups?

Was use_new_descriptions_for intentionally changed from list to dict in recent 2.4 patch levels?

Will this issue be solved if every site gets migrated to the same version, for instance 2.4.0p30?

2

it might just be that the update failed on your remote site. I would assume “omd update” would have also reported that, but maybe it didn’t, if you still have the logs, you can check in ~/var/log/update.log)

what does your global.mk file look like after you run “cmk-update-config” (possibly with --site-may-run if you don’t want to stop your site :wink:

and does that fix it permanently even after you push config from your central site?

3

This is an incompatible change that was introduced around p25. I had also a distributed environment where I updated one site first to p28 from p25 and had the same error.

4

Hi,
thanks for the confirmation.

The update itself completes fine, so i can safely assume that the configuration file gets migrated without problem. The issue appear after I push the changes from the central site to the remote one.

After every site gets updated to the same version, does the issue is confirmed to disappear ?

5

After update all sites it will be ok again.