Dummy service to modify host variables

This forum was archived to /woltlab and is now in read-only mode. Please register a new account on our new community platform.

You can create a thread on the new site and link to an archived thread. This archive is available as knowledge base, safe and secured.

More details here.
  • Hi,

    I've tried for quite a while now to create dummy services that should modify host variables, and boiling it down to the bare minimum (see my test service below), finally concluded that it doesn't seem to work at all. An example of what I would ultimately want to achieve is to have a check that parses the return string from another OS check and sets for example the host variables System, Distro, Version and Kernel for use with the Icingaweb2 cube module. Am I missing something that allows this to work?

    This is my current test service that tries to set both host and service variables, but both just ends up with the empty string even after check execution. The string return is just to be absolutely sure that the lambda function has indeed been called:

  • Even if you get this to work somehow - modifying custom attributes won't update the database backend and as such you won't see them inside the cube module.

    "host.vars.host_test" and "service.vars.service_test" are not available inside the apply scope here. Inside the anonamous runtime function they might be, but the more interesting question is - why do you need to modify those custom attributes at runtime? I would go the static route and only pre-define custom attributes on the host and service level itself (and inherit that from the host for example).

  • I was expecting that, yes. For the OS thingy, I agree. It's not something that is likely to change often, especially the platform and distro or even the version, so inheriting those from a template or two and overriding the ones that need it would be easy. Getting the kernel version could be slightly more useful though, given that we're not using a cmdb of any kind. I was also hoping to be able to use it for things like the version number of one of our custom deb packages, again for a drill-down application with cube. Ah well. It was worth a try, and if I want it enough, I suppose I could always have a go at forking cube to have it use check return strings instead of variables. Thanks :)

  • I was btw wrong about the custom attributes changes not reflected in the database; that happens based on SetVersion() and the OnVersionChanged handler independent from any interface.

    Still things like get_host("foo").vars.foo ="bla" won't work as such, since they do not trigger an object update from just setting an attribute via runtime lambda functions. We had such a feature request ourselves when implementing the API and console, but that never happened as implementation.

    That's for the technical background, TL;DR - find a better alternative :) Btw - maybe you can create a configuration option for the cube, or even discuss it with Tom to not only allow custom attributes as source, but also check output (over at Github).