New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dev.icinga.com #13389] bash command output available in configuration files #4819
Comments
Updated by tgelf on 2016-12-05 13:44:40 +00:00 pros:
cons:
In the meantime you could give Icinga Director a look. It provides import property modifiers to solve exactly this problem, and there are also multiple ones dealing with DNS lookups. They are configurable and let you for example specify that an unanswered lookup would either store the DNS name, leave the field empty or let the whole import run fail. Cheers, |
Updated by mfriedrich on 2016-12-06 17:28:14 +00:00 I am pro and contra in a similar way like Thomas is. I also do see problems with creating file dependencies referenced in those calls. What if they do not exist on a certain cluster node where the configuration is loaded? That involves in-depth knowledge about synchronising such as well. And it certainly involves additional documentation, support & troubleshooting. The Icinga 2 DSL already is somewhat dynamic and feels uncontrollable at some point. This would add a yet more complex difficulty level to it. Still, I am open for discussion. What do others think of that? |
Updated by pooh on 2016-12-06 18:37:28 +00:00 I'd like to think that the admins who make use of such a feature can be responsible about the scalability - it may not be appropriate for really big installations - but it could still be useful for smaller ones. I think Thomas' comment that "as this would be called for every host, it would hammer your external data source" may be true for the DNS lookup example I gave, but for other uses it would only be called for a small number of hosts. Also, regarding the "bad consequences", I'd hope that the admin using this would create logic around the system call in the configuration stanza so that timeouts or other inappropriate output don't make a complete mess of the object definition. I'm not sure I see any greater problem with file dependences on various cluster nodes than already exists with custom plugins etc - you can reference them in your configuration and have it pushed to all the nodes, but you still have to separately ensure that the plugin scripts exist where they are needed. |
There's no progress here, nor would we want to implement it. Closed. |
This issue has been migrated from Redmine: https://dev.icinga.com/issues/13389
Created by pooh on 2016-12-02 18:15:07 +00:00
Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-12-06 18:37:28 +00:00 (in Redmine)
I'd like to have a function which I can call in a configuration file to get the output of a bash command.
Specific example: I define hosts by their FQDN; I'd like to be able to create a template which says "define 'address' if there is an IPv4 A record for that FQDN" and "define 'address6' if there is an IPv6 AAAA record for that FQDN", so that it's automatic for all hosts (and also updates on reloads if a record gets added or removed, for example).
I'm sure there are other use cases, but this is what I was trying to do when I found out there's no "system()" call, or backtick notation, in icinga2 configuration files.
The text was updated successfully, but these errors were encountered: