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 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
Have a nice weekend!