Add activation priority for config object types #6270
Conversation
|
This is still a WIP (there are debug messages and a sleep to help debug). Please use this PR to discuss changes to the Priorities. |
|
So far, this works fine in my tests in provoking notifications prior to a downtime object. |
This patch ensures that specific configuration types are pre-activated and post-activated. In general, logging is first, then common configuration objects like host/service, downtimes, etc. In the end, all features are activated after to ensure that notifications are only sent once downtimes are applied. A similar thing happens for starting with checks too early. The ApiListener feature runs first to allow cluster connections at first glance. fixes #6057 fixes #6231
bb03e6b to
c54e042
Compare
|
Squashed, amended and rebased. Looks good to me. |
|
Technical note: The patch adds a feature to our class compiler which parses the .ti files into actual code. This renders it easier to specify the priority just for the type instance from any library. This is necessary since lib/config doesn't know anything about our config object types. The major change happens in the config compiler within ActivateItems() where the type sort order relies on the priority and enforces that on the config object activation order. |
|
Note aside: This is a big change and should be tested with the snapshot packages once available. Backports are only an option after successful tests with the snapshot packages. |
|
Thank you for this fix! Especially @Crunsher 🎉 |
This PR adds an
activation_priorityoption to all icinga objects. Objects are activated in order of their activation, with the lowest going first and the highest last.The default is 0.
Currently the priorities are as follows
Loggers (FileLogger, SyslogLogger) We want these first to make sure any errors are logged
Everything else. Mostly Config items (Hosts, Services, Downtimes...)
ApiListener. Stated after config but as the first feature since we want it available asap. A bit of premature optimization possibly.
Features (CheckerComponent, CheckResultReader, CompatLogger, ExternalCommandListener, StatusDataWriter, IdoConnections, LivestatusListener, NotificationComponent, ElasticSearchWriter, GelfWriter, GraphiteWriter, InfluxdbWriter, OpenTsdbWriter) These are activated last to make sure they don't act before all config objects are there.
fixes #6057
fixes #6231