Apply rules for hosts, mixing Director and static files

Icinga Web Modules Icinga Director
, ,
1

Hello,

Using icinga + Director last versions, and though I read this
https://community.icinga.com/t/apply-rules-for-host-objects/2368, I found the answer was quite short.

The logic of my setup is as such : I’m trying to set up the most disposable configuration in the world, having absolutely everything created from automation (hosts, services…) and keeping nothing defined statically.
For that, I’m using modules that allow me to import and created hosts objects on the fly, and regularly delete the all - they get re-created some times later.
I’m using import modules like vspheredb, proxmox pve, x509, netbox, and they are all helping me to create the needed objects.

Now, it looks like I reached the end of what I can automate, and I now need to add some specific variables to this volatile hosts (host.vars.custom01 = 42).
I could manually add these vars after the hosts are created (web gui, REST API…), but obviously, I would need to manually repeat this action.

For the services objects, I’m using service apply rules, thus nothing has to be done manually.
For the hosts objects, there seem to be no similar mean.

I was thinking about writing the needed host.vars declarations in a static file, but I guess they will collide with what Director will produce and the known universe will obviously collapse or worse : the icinga daemon will refuse to restart.

May some of you have any comments about the collapsing universe?

2

Hello @nec!

Sounds like you want this:

I.e.:

on_config_committed {
  get_host("foobar").vars.custom01 = 42
}

But meanwhile you could define:

template Host default {
  if (this.name == "foo") {
    vars.bar = 42
  }

  if (this.name != "foo") {
    vars.bar = 23
  }

  ...
}

Best,
A/K

3

Hello Alex (@Al2Klimov ),

That sounds very interesting, and opening amazing perspectives.
Thanks for pointing me to that feature.

Just to be sure about your last advice, about managing the “default” template : is this a reserved word (“default”) which I can use to supersede what’s behind, or should I manually take care of the inheritance of this default template towards my existing templates?

Nico

4

Yes, default is a magic keyword. All hosts would inherit a such template.

5

Sorry for digging out this old thread, but coming back to work on this subject, I’m witnessing that when trying to use “template Host default” in /etc/icinga2/conf.d/myCompany.conf file, this var.foobar does not seem to be taken into account.

On other posts, I read that the conf.d files were evaluated based on their filenames, but I don’t know :

  • in which order
  • whether if was still relevant

Maybe you know more about that?

6

If you think a template of an if in it isn’t applied, temporarily add throw "debug" there and run icinga2 daemon -C. If the latter doesn’t complain, you know for sure that it’s not applied.

7

Hello,

I tried to use “throw debug”, and indeed, I saw that this file was read and additional tests showed that the content of this “template Host default {…}” config was read and taken into account.

But here is what I’m witnessing :

In this same conf file, if I create a host, and then I use the default template above to setup some vars, this is working (I can see it in “icinga2 object list” output and in icinga web).
But if I try to use this to setup some vars on hosts that were created by Director, though using their correct names, the vars are not applied.

I dream that some devs get to read my comment and explain why this is not working because there must be a reason.

So far, it looks like I have no way to modify any host created by Director.

8

nearly all checks depend on custom vars, imagine you can change them via icinga2 api:

  • you deploy again in director => which var value should be used?
  • someone wants to find out what’s wrong with a check but has no shell access, it could be difficult for the user to find out why the vars are not applied…

You can use icinga diretor api to change these vars too, but you require a deploy to apply them

9

You should put that template into a global zone instead I guess.

10

Hello,

Quick update here : In the end, using the "template Host default { if… } did work, so Thank you to all who replied here.

I suppose that the next icinga development step will either be host templating, or on_config_commited feature.

Have a nice day.

Nicolas