GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
This issue has been migrated from Redmine: https://dev.icinga.com/issues/1882
Created by wpreston on 2011-09-09 09:46:25 +00:00
Status: Resolved (closed on 2013-11-20 16:20:51 +00:00)
Target Version: 1.11
Last Update: 2013-11-20 16:20:51 +00:00 (in Redmine)
If macros (e.g. $SERVICEDESC$) are contained in the notes url (a common occurrence...)
they are not expanded, and the Links are useless.
2013-11-20 15:35:00 +00:00 by mhein bdaf233
Implement macro expander
2013-11-20 15:44:14 +00:00 by mhein 1d337a1
Merge branch 'feature/macro-expander-1882' into next
Updated by mfriedrich on 2011-09-09 10:32:30 +00:00
see #1883 - the idoutils do not dump the processed macro string, but the plain string. the cgis call themselves the shared marco fetching functions which are not really possible for a database based solution. better attempt would be to insert that into the database via data output.
Updated by jmosshammer on 2011-09-12 10:03:55 +00:00
I think this should be done in idoutils, as it should provide an abstract interface for icinga data and should hide (data storage) implementation details like macro expansion from developers. We (and other people using the db) would have to care which macros exists, where they occur, how they are resolved and constantly check if there are new macros. I would really appreciate if we could solve this in the idoutils.
Updated by wpreston on 2011-09-12 14:05:01 +00:00
I only see this as being a problem for dynamic macros (e.g. $TIMET$).
But we could live without the time macros being updated.
Of course it would be nice if custom macros were dynamically expanded,
because we could alter them with the CHANGE_CUSTOM_HOST_VAR command - but since
this doesn't work with the classic interface either, it's not a big problem.
I have a strong suspicion though that macros aren't available to the core at the point the configs are dumped :-(
Updated by jmosshammer on 2011-09-26 16:13:34 +00:00
Updated by mfriedrich on 2011-12-08 12:39:38 +00:00
Updated by mfriedrich on 2012-04-30 18:26:04 +00:00
grabbing the macros on dump will add more complexity and wait time on the actual insert/update then. this cost remains too high, especially when you run the core with gprof - most likely you will see that the macro grabbing is one of the most run.
Updated by jmosshammer on 2012-09-12 12:51:39 +00:00
1.8 is here soon and we don't have a good solutiion for this yet, so I'll pospone to 1.9.
Updated by mfriedrich on 2012-10-24 16:50:52 +00:00
consider it as a todo when we start digging around icinga2's api. i doubt that the current 1.x framework will support that due to the lack of performance.
Updated by mfriedrich on 2012-11-21 14:37:36 +00:00
Updated by mfriedrich on 2013-07-20 11:52:17 +00:00
will be done with #4432 as new feature request then (additional columns used).
Updated by mfriedrich on 2013-11-12 18:47:36 +00:00
Updated by mhein on 2013-11-15 15:09:45 +00:00
Updated by mhein on 2013-11-15 15:09:53 +00:00
Updated by mhein on 2013-11-20 10:38:00 +00:00
Updated by mhein on 2013-11-20 16:20:51 +00:00
Applied in changeset 1d337a1.