Icinga2: Problems with object activation/updates on diff dumps in DB IDO

[dnsmichi]

There are various reported problems for this. This issue collects them all, as they all relate to each other. It also increases visibility on GitHub.

• [ ] 'recreated' API objects are not (always) active in IDO DB #5205 #6927
• [ ] Deleted objects not deactivated #6866
• [ ] Group members are missing in the IDO for newly-created groups #4811
• [ ] update of icinga_timeperiod_timeranges after config change #4659
• [ ] IDO isn't updated on check_period removal #5037 #6744
• [ ] CV update issues #6569

A possible fix should include all of them. PRs welcome.

Workaround

mysql icinga

update icinga_hosts set config_hash=null;
update icinga_service set config_hash=null;
update icinga_timeperiod set config_hash=null;

exit

systemctl reload icinga2

Notes

• groups and timeperiod_timeranges are referenced tables
• check_period might not be included in the hash check
• object deletion and creation might not trigger events at runtime (OnVersionChanged)

[Crunsher]

6569 could be added to the list

[dnsmichi]

This is a candidate for a wont-fix, leaving this open up until IcingaDB is released.

[dnsmichi]

@Al2Klimov Why did you close this without further comment?

[Al2Klimov]

Because it's a won't-fix.

[Thomas-Gelf]

Thanks @dnsmichi. Incomplete IDO config refreshes are a massive problem for some of our customers, IMHO this should be fixed with urgency.

[dnsmichi]

Ok, seems this was not clear from the description, I have removed the label.

From discussions in the past - even when IcingaDB is released, it will take months or years until everyone has migrated from the IDO backend to the new backend.

Also, not fixing IDO related issues will only work when it officially is deprecated. Which imho is not possible at the very moment, correct me if I am wrong @lippserd.

@Thomas-Gelf I cannot influence the time resources here, but at least the config_hash problems in various environments should be tackled in the coming months. There sometimes is a problem with the algorithm detecting whether to fire a full heavy config update vs a light one. I don't know why exactly, but the hash calculations for object attributes need a review.

In order to avoid multiple issues tackling the same problem, this issue shall remain open as a reminder and global task list.

[Thomas-Gelf]

I have no problem with major similar issues being combined into a single dedicated issue. At least when such issues are then somehow prioritized. It becomes problematic once we re-label such combined issues into an evaluation/reminder/maybe-issue. Those then tend to be silently stalled/wontfixed/closed.

@lippserd: I'm aware of at least one large setup that faced this issue multiple times. They're running scary workarounds in production and strongly believe that this is gonna be fixed. It would be fantastic if we could schedule this. Just to make sure that it will not be forgotten ;-)

Thanks,
Thomas