Skip to content
This repository has been archived by the owner. It is now read-only.

[dev.icinga.com #1882] Icinga macros not expanded in notes|action_url #490

Closed
icinga-migration opened this issue Sep 9, 2011 · 15 comments
Closed

Comments

@icinga-migration
Copy link
Member

@icinga-migration icinga-migration commented Sep 9, 2011

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

Assignee: mhein
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.

Changesets

2013-11-20 15:35:00 +00:00 by mhein bdaf233

Implement macro expander

refs #1882

2013-11-20 15:44:14 +00:00 by mhein 1d337a1

Merge branch 'feature/macro-expander-1882' into next

resolves #1882

Relations:

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Sep 9, 2011

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.

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Sep 12, 2011

Updated by jmosshammer on 2011-09-12 10:03:55 +00:00

  • Status changed from New to Feedback

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.

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Sep 12, 2011

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 :-(

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Sep 26, 2011

Updated by jmosshammer on 2011-09-26 16:13:34 +00:00

  • Category set to Architecture
  • Target Version set to 76
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Dec 8, 2011

Updated by mfriedrich on 2011-12-08 12:39:38 +00:00

  • Target Version changed from 76 to 1.8
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Apr 30, 2012

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.

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Sep 12, 2012

Updated by jmosshammer on 2012-09-12 12:51:39 +00:00

  • Target Version changed from 1.8 to 1.9

1.8 is here soon and we don't have a good solutiion for this yet, so I'll pospone to 1.9.

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Oct 24, 2012

Updated by mfriedrich on 2012-10-24 16:50:52 +00:00

  • Target Version changed from 1.9 to 1.10

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.

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Nov 21, 2012

Updated by mfriedrich on 2012-11-21 14:37:36 +00:00

  • Subject changed from Icinga Macros not expanded in notes URL to Icinga macros not expanded in notes|action_url
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Jul 20, 2013

Updated by mfriedrich on 2013-07-20 11:52:17 +00:00

  • Status changed from Feedback to Closed
  • Target Version deleted 1.10

will be done with #4432 as new feature request then (additional columns used).

@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Nov 12, 2013

Updated by mfriedrich on 2013-11-12 18:47:36 +00:00

  • Status changed from Closed to New
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Nov 15, 2013

Updated by mhein on 2013-11-15 15:09:45 +00:00

  • Assigned to set to mhein
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Nov 15, 2013

Updated by mhein on 2013-11-15 15:09:53 +00:00

  • Target Version set to 1.11
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Nov 20, 2013

Updated by mhein on 2013-11-20 10:38:00 +00:00

  • Status changed from New to Assigned
@icinga-migration
Copy link
Member Author

@icinga-migration icinga-migration commented Nov 20, 2013

Updated by mhein on 2013-11-20 16:20:51 +00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 0 to 100

Applied in changeset 1d337a1.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.