Closed icinga-migration closed 5 years ago
Updated by tgelf on 2016-11-18 10:27:53 +00:00
Updated by tgelf on 2016-11-18 10:28:07 +00:00
Updated by tgelf on 2016-11-25 10:26:54 +00:00
Updated by tgelf on 2016-12-15 15:55:17 +00:00
Do you have an Estimate on that Ticket?
No
Related and nearly finished: #832
The parts related to group membership habe been implemented, vars an properties will be postponed unless IcingaDB got shaped.
I would be interested in picking up working on this issue as it appears to have been in the pipeline a while.
@thomas-gelf are you able to advise on the direction you were taking with this? Could you give me a quick summary of your thoughts etc and I will review the existing commits as well
Please follow #1984
This issue has been migrated from Redmine: https://dev.icinga.com/issues/13068
Created by tgelf on 2016-11-08 10:40:33 +00:00
Assignee: tgelf Status: Assigned Target Version: 1.4.0 Last Update: 2016-12-15 15:55:17 +00:00 (in Redmine)
We have a bunch of features that would benefit from a resolve cache for all our objects. This would involve introducing a bunch of additional tables, mostly reflecting the current structure. Related properties should be resolved to flat structures, with nested custom variables being the trickiest one. Focus should be on performance, ideally all related queries should be able to execute based on available indexes.
Filters and matching objects should also be persisted. Searches in the GUI could benefit from the same structure, but such entries should be timed out after a little while. Is is essential that also "group membership" constructs are handled in an efficient way, and that the related solution cleanly applies to other array-typed values (think: tags, permissions based on such or similar).
Changesets
2016-12-15 18:45:22 +00:00 by tgelf 07b6090c3177299fad240ad4315f6182f504d1ef
2016-12-16 11:19:57 +00:00 by tgelf ec0cbac657ac1830ae694554d43fa9d120e28588
Relations: