Adding values to arrays in director in template inheritance

Icinga Director
1

Hi there,
I want to use template inheritance for something like this

  • windows-generic
    • defining C: disk
  • linux-generic
    • defining / and /tmp

Now child templates like

  • win-sql should inherit windows-generic and add E: and F: without loosing C:
  • dsm-62 should inherit linux-generic and add /data without loosing / or /tmp

This seems not to work. As soon as I define one additional disk in the child template I am loosing all parent values as director is not offering the operators to differentiate between adding or overwriting.

Best,
Matthias

P.S. By the way I am somehow missing the possibility of multi-dimensional arrays in data fields in director? Am I right?

2

Can you show the resolved templates configuration ?

I have used inherited templates and it worked with no issues.

What version of Icinga & Director are you using ?

3

Hi,

in terms of nested dictionaries and arrays, the Director provides only a limited set of the Icinga 2 DSL. Which basically means that you need to use flattened values and cannot use advanced techniques shown in the Icinga 2 DSL examples with nested apply for loops and so on.

In terms of the question, let’s see about this - no Director pro, still learning myself. I’m using the Vagrant box standalone which includes Director 1.6.0.

Template Inheritance

  • Define a new data field disks as array

director_new_data_field
director_new_data_field1052×446 38.1 KB

  • Define the host template windows-generic, add disks as field, add C: as values in the template

director_new_host_template
director_new_host_template1663×761 91.6 KB

director_new_host_template_fields
director_new_host_template_fields1669×549 61.3 KB

director_new_host_template_custom_properties
director_new_host_template_custom_properties1664×779 92.5 KB

  • Add host win-sql, import the windows-generic template, and set disks as custom property to E:

  • Deploy the config and render it

director_host_render_config
director_host_render_config1669×785 99.3 KB

Conclusion: Additive assignments for array lists are not supported in the interface.

Service Sets

So, I just sat down and remembered what I’ve tried a while ago with analyzing a problem in Icinga and the Director.

I do think that service sets exactly solve your requirement, but you need to try them out.

Since this got pretty long with many screenshots, I’ve moved it into the howto section. I guess this is one of best strategies inside the Director without much docs :slight_smile:

Director Service Sets: Add service checks based on host templates

Conclusion

Try it out and see if that fits your problem. It requires a little change in your thinking and strategy.
I’ve written this at work, improving my Director skills once more and even getting direct Feedback from Tom.

Cheers,
Michael

3 Likes
4

Hi @aflatto,
I use icinga 2.10.2 with director master git from last week?
I double checked it and it seems that mfriedrich comment supported my issue…

  • host-template-generic: vars.disks=/
  • host-template-1: vars.disks=/tmp, inheriting host-template-generic
  • assign host-template-1 to host, see vars…will have only /tmp

Best,
Matthias

5

Hi @dnsmichi
thanks for your detailed reply and following howto…really appreciating it…
I tried it out and thought about it a lot…I think it is not such a good workaround for the purpose what the multi-dimensional arrays may / should / can be used for…
Especially if I think about how many single data fields I would have to define because of combinations…uh…:frowning:

I think then I will work with my old mindset again…just using host-groups with services and servicesets assigned without the detour of using variables inbetween.

Best,
Matt

1 Like
6

Hi,

a bit of background here: When we first started with Icinga 2, we’ve invented the apply rules. Simple and “stupid”, but still, a huge improvement over the old 1.x configuration format. After a while, the DSL got loops with for/white/etc. … well, just because we could add this. Then users asked if they could combine “apply” and “for”, which resulted in nested dictionaries and “apply for” configuration automation.

At that time, this hasn’t been designed nor considered for the Icinga Director. “apply for” was released with 2.2.0, and it took us up until 2.4.0 to implement a REST API where later on the Director could interact with Icinga 2.

Putting all the things from the Icinga 2 DSL into a configuration tool is really hard. The Director aims to provide a) a web configuration frontend b) automate config imports and integrate external tools.

History tells that Director users have a different view and requirement on the way they organize objects, inheritance and additional attributes. The Director abstracts a lot of these things and generates Icinga 2 configuration then. Still, it invents its own strategy and adds more cool ideas like the service sets.

I haven’t touched more excludes possible with service sets, as this would be too complicated. I will come back to this when more details are asked here :slight_smile: The thing about template trees and preparing this “set” for later management is key in the Director, you should always keep that in mind.

In the end, the Icinga 2 DSL and the Director share a common feature set, but both provide their own strategy. This currently isn’t highlighted good enough in the “getting started” docs, and we’ve agreed in our strategic workshop in late 2018 to change/enhance this for beginners in the coming months - making the Director the first class citizen you’ll start with before even opening vim to edit the DSL.

That being said, I hope you find you way through it, and if not, just ask. We’re here to help :slight_smile:

Have a nice weekend!

Michael

1 Like