I’m using a mix of Icinga Director and config management to push out Command configs and the recent update overlapped with some I had already created. That caused icinga2 to fail to restart (post update) and even after I fixed the overlap on the master and in Icinga Director, the changes couldn’t be pushed out since the satellites were not able to start. This led to me having to update /var/lib/icinga2/api/zones/global-templates/_etc/commands.conf manually on a bunch of servers. /gripe
I’m wondering if there is a better way to approach this or if there is another way to implement having a mixture of configs to avoid this type of issue. I don’t have the budget for a full fledged test environment where I could have seen this coming and changed my names first before the update was pushed.
Or is this just the unavoidable nature of having contrib configs as part of the icinga2-common package?
I suppose I could cherry pick configs I want out of the contrib dir and push them as needed, excluding the contrib from being imported by commenting out include <plugins-contrib>?
Has anyone else run into this problem? If so, I’m curious how you are orchestrating these various levels of configurations.
I would recommend to choose just one way to do the configuration. A mix of multiple options is just a bit more error prone. But I let this topic to those that are more experienced with similar setups and might have good tips for you.
Regarding:
This led to me having to update /var/lib/icinga2/api/zones/global-templates/_etc/commands.conf manually on a bunch of servers. /gripe
Next time, you can just drop the content of the zones folder. The content in these folders should be modified by icinga2 only and it will be synced if the directory is empty.
I don’t think only using one configuration would help (unless I also comment out plugins-contrib). And if I comment out plugins-contrib, I can manage the naming overlap between my config changes and Icinga Director changes.
I edited /var/lib/icinga2/api/zones/global-templates/_etc/commands.conf since it was last synced from the master. Since the service needs to be running for the satellite to obtain the new version of it - out of luck when it can’t start (chicken vs. egg).
It is a known problem, yet I have not found a subtle solution for it. As simple as it goes - config from two sources, kab00m. The template library has one big benefit - literally 90% of the users don’t care about creating cumbersone commands with command lines, arguments, escaping since it is already there.
2.11 includes some new plugins, that’s true. It is not explicitly explicitly listed in the Changelog which are new - that’s up to the reader with following the milestone URL and checking the ITL related updates.
I know that running yum update is far more easy than reading changelogs, but the past has proven me right that no-one reads them and then complains about changes. Read those changelogs and upgrading docs, I am not writing them for the fun and pride.
I’m not sure what’s the best solution since an “if user has it, don’t use ITL” algorithm is really hard to implement - also in a way that existing installations don’t break.
@dnsmichi I’m happy to see more commands available out-of-the-box and I hope I didn’t come off as complaining. I merely intended opening the floor to see if there were any strategies other people used to help with the merge when overlap does occur, maybe I just wasn’t thinking of a better approach, etc.
One solution could be similar to the same logic as import: last one wins. In this case the duplicate commands would be ignored and the config from the last-loaded one would be used. Some drawbacks would be if the order were not transparent it could lead to bugs/frustration trying to find the correct config to change.
Maybe an option to “ignore_duplicate_commands” set to False by default (allowing for temporary override to get the service back up and sync’ed which addresses the deadlock/chicken-egg problem).
No worries, it was a day full of complaints and the tone in various posts and issue was emotional with frustration. I tried to not let that influence me, but in this case I’m sorry for the harsh tone.
Interesting idea on the ignore_duplicate_commands thingy. Thing is, we would likely need a solution for generic config objects. There actually is a hidden “ignore_on_error” methodology but that’s only used internally and likely not a good way to expose to the users. An extra config flag always is cumbersome.
But I kind of like the idea that ITL provided config objects are “volatile” and can be replaced with actual user configuration. Maybe you can think about this a little as well, and write some more things down - and create a feature request on GitHub
I sort of figured there would be an uptick after the update, and I certainly didn’t mean to pile on. I wanted to float that idea before putting too much effort into it (actually just thought of it while considering a reply to your first response)…I’ll give it a deeper look and put something over on github. Have a great weekend as well!
