Skip to content

Conversation

Donien
Copy link
Member

@Donien Donien commented Jul 9, 2025

This PR does the following:

  • Merge icinga2_objects in RAM
    Objects are now merged in memory instead of writing them to files and then merging them after the fact.
    They are still separated into multiple files if decided by the user (e.g. every host could have their own file or all hosts could share the same file; the latter is more time efficient).
    This yields a great performance increase (up to 80% time savings)

  • Drop the order parameter
    The order parameter used in objects is no longer taken into account.
    If order is used in icinga2_objects, there will be a deprecation warning. Other than that it will just be ignored for now (order of objects is now down through python sorting a list of dictionaries (objects) to keep idempotency).

  • Change structure in /var/tmp/icinga/
    Since files are no longer assembled, the directory structure needed to change a bit.
    If running the new approach in an old environment, the directory structure will not be correct. What is now being treated as a file path has been a directory path previously (target_path.conf/ vs. target_path.conf).
    Writing objects will fail!

    There is an easy, one-time fix: Delete /var/tmp/icinga/ once.
    This removes the old structure and makes room for the new one.

    This is also noted in the changelog fragment.

Side note: In the future we could get rid off writing to /var/tmp/icinga altogether since this was only used to have a place in which to assemble multiple files into new ones.

@Donien Donien requested a review from mkayontour July 9, 2025 13:23
@Donien
Copy link
Member Author

Donien commented Jul 9, 2025

This might close #338 and #339.

Closes #386

@Donien Donien force-pushed the enhancement/icinga2-objects branch from 4c4c0a6 to 6a292dd Compare September 2, 2025 15:49
@lucagubler
Copy link
Contributor

Is there an approximate timeline for when this PR can be merged?

Copy link
Member

@dgoetz dgoetz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My first test with the change results directly in an error:

fatal: [monitoring.localdomain]: FAILED! => {"msg": "An unhandled exception occurred while templating '{{ (icinga2_config_directories | select('match', '^conf.d/.*')) + (icinga2_config_directories | select('match', '^zones.d/.*')) + (icinga2_config_directories | select('match', icinga2_confd)) }}'. Error was a <class 'ansible.errors.AnsibleError'>, original message: Unexpected templating type error occurred on ({{ (icinga2_config_directories | select('match', '^conf.d/.*')) + (icinga2_config_directories | select('match', '^zones.d/.*')) + (icinga2_config_directories | select('match', icinga2_confd)) }}): first argument must be string or compiled pattern. first argument must be string or compiled pattern"}

My test playbook can be found at https://github.com/NETWAYS/foreman-training/blob/gh-pages/_files/share/icinga-preparation.yml (just adjusted the namespace locally yet) which contains only 3 ApiUser objects.


A performance gain of up to 80% has been seen in testing.

known_issues:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we simply avoid this issue by cleaning the directory earlier? I think this would be a good practice anyway so we are sure no manually interacting happened.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this right now.
There was a lot of thoughts put into this to keep idempotency.

I think it's worth revisiting this, especially because we might be able to get rid off icinga2_fragments_path / /var/tmp/icinga altogether since we do not need to merge files anymore.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we will get rid of it in the future no need to make it more complicated.

@Donien Donien force-pushed the enhancement/icinga2-objects branch 2 times, most recently from d3011f6 to 478f5b3 Compare September 26, 2025 16:52
@Donien
Copy link
Member Author

Donien commented Sep 26, 2025

My first test with the change results directly in an error:

fatal: [monitoring.localdomain]: FAILED! => {"msg": "An unhandled exception occurred while templating '{{ (icinga2_config_directories | select('match', '^conf.d/.*')) + (icinga2_config_directories | select('match', '^zones.d/.*')) + (icinga2_config_directories | select('match', icinga2_confd)) }}'. Error was a <class 'ansible.errors.AnsibleError'>, original message: Unexpected templating type error occurred on ({{ (icinga2_config_directories | select('match', '^conf.d/.*')) + (icinga2_config_directories | select('match', '^zones.d/.*')) + (icinga2_config_directories | select('match', icinga2_confd)) }}): first argument must be string or compiled pattern. first argument must be string or compiled pattern"}

My test playbook can be found at https://github.com/NETWAYS/foreman-training/blob/gh-pages/_files/share/icinga-preparation.yml (just adjusted the namespace locally yet) which contains only 3 ApiUser objects.

I found the problem.
icinga2_confd can be either true or false OR <some-directory>.

I always test with something like icinga2_confd: local.d/ and thus didn't catch the true / false cases.

They should now be dealt with as of my latest force push (I also rebased with current main).

@Donien Donien force-pushed the enhancement/icinga2-objects branch from 478f5b3 to 2c3fb43 Compare September 26, 2025 17:02
Copy link
Member

@dgoetz dgoetz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested it again with an existing environment and a new one without any issues.

For an existing environment I had the expected configuration changes in the first run, because of the removed order even I had not used the parameter, but no changes in additional runs.

Created also a test with order which gets ignored as expected issuing a deprecation warning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants