# Override vars not working for service-applies **URL:** \ **Category:** Icinga Director\ **Tags:** icingaweb2, director\ **Created:** [February 21, 2019, 8:48am UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429 "2019-02-21T08:48:10Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![blindzero](https://community.icinga.com/user_avatar/community.icinga.com/blindzero/32/134_2.png) [@blindzero](https://community.icinga.com/u/blindzero)\ **Post date:** [February 21, 2019, 8:48am UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/1 "2019-02-21T08:48:10Z")
Hi everybody, based on the following setup: - icinga2 r2.10.2-1 - icingaweb2 2.6.2 - director 1.6.1 (master) I have set up the following: - service template \_srv\_disk\_win with inherited disk\_win\_crit and disk\_win\_warn from command - service apply “Disk $config$”, importing \_srv\_disk\_win and applying host.vars.disks: apply Service for (config in host.vars.disks) { name = "Disk " + config import “_srv\_disk\_win" assign where match("win_\*”, host.vars.os) vars.disk\_win\_path = config import DirectorOverrideTemplate } - a host service override for a specific host object Host “myhostname” { import “\_host\_generic” import “\_os\_win-srv-2008r2” import “\_net\_internal-lan” display\_name = “My Server” address = “1.2.3.4.” check\_command = “hostalive” vars["\_override\_servicevars"] += { “Disk $config$” = { disk\_win\_crit = “5%” disk\_win\_warn = “10%” } } vars.disks = [“C:\”, “D:\”] } However, the servicevars override is not used in the check…the service is warning disk c: at 15% free. Inspecting the service shows only “vars { disk\_win\_path: “C:\” }” I found a bug @Github but which was fixed in Mid-2018. Any ideas? Best, Matthias ---
**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\ **Post date:** [February 22, 2019, 9:47am UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/2 "2019-02-22T09:47:08Z")
This is using an apply for rule which looks into `host.vars.disks` and iterates over the array elements. The overriding import of the template doesn’t look good in the host object, especially the `$config$` string will never match nor will the template override be aware of this. Yet, I am not sure if apply for loops fully support such service overrides. At least the name expansion to “Disk C:” is missing in order to override the specific variables. Which steps were taken in the web interface to achieve exactly this situation, best with screenshots? Maybe we can reproduce the question with you. Cheers, Michael ---
**Author:** ![blindzero](https://community.icinga.com/user_avatar/community.icinga.com/blindzero/32/134_2.png) [@blindzero](https://community.icinga.com/u/blindzero)\ **Post date:** [February 26, 2019, 8:31am UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/3 "2019-02-26T08:31:01Z")
Hi @dnsmichi thanks for your reply… I did some screenshots, I hope I catched everything to gather the config path. But due to community limits I have to split it up… **External Command** ![ext-command_disk-win_config](https://community.icinga.com/uploads/default/original/1X/12b10f71fbd9aa0e73b6615c7058ec3e9090536b.png) ![ext-command_disk-win_preview](https://community.icinga.com/uploads/default/original/1X/64576ba72862972557b81efbc8f5eb5e722acf47.png) ---
**Author:** ![blindzero](https://community.icinga.com/user_avatar/community.icinga.com/blindzero/32/134_2.png) [@blindzero](https://community.icinga.com/u/blindzero)\ **Post date:** [February 26, 2019, 8:31am UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/4 "2019-02-26T08:31:32Z")
Using it in a **Service Template** ![srv-template_disk-win_config](https://community.icinga.com/uploads/default/original/1X/b4ffce088830d9402225bf17ad28b6426f02f95a.png) ![srv-template_disk-win_preview](https://community.icinga.com/uploads/default/original/1X/9125ab64b4fda8476dc98ae5b607365d2585da14.png) ---
**Author:** ![blindzero](https://community.icinga.com/user_avatar/community.icinga.com/blindzero/32/134_2.png) [@blindzero](https://community.icinga.com/u/blindzero)\ **Post date:** [February 26, 2019, 8:32am UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/5 "2019-02-26T08:32:03Z")
Applying this service via **apply rules** ![apply-rule_diskS-win_config](https://community.icinga.com/uploads/default/original/1X/f1046708d33b7d4a9824abaedcd87470f40ceeee.png) ![apply-rule_diskS-win_preview](https://community.icinga.com/uploads/default/original/1X/4cc8c08707fb42bddf2fb069f65ef1aea061d53d.png) ---
**Author:** ![blindzero](https://community.icinga.com/user_avatar/community.icinga.com/blindzero/32/134_2.png) [@blindzero](https://community.icinga.com/u/blindzero)\ **Post date:** [February 26, 2019, 8:32am UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/6 "2019-02-26T08:32:35Z")
Overwriting service settings in **host config** ![host_service-disk-applied_overwrite-config](https://community.icinga.com/uploads/default/original/1X/ccf8ec7639cc47551e50c9b561a76dae83514630.png) ![host_service-disk-applied_overwrite-preview](https://community.icinga.com/uploads/default/original/1X/f3c3a21e48b943d33af01a02e38060375ba8c33c.png) ---
**Author:** ![blindzero](https://community.icinga.com/user_avatar/community.icinga.com/blindzero/32/134_2.png) [@blindzero](https://community.icinga.com/u/blindzero)\ **Post date:** [February 26, 2019, 8:33am UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/7 "2019-02-26T08:33:25Z")
**Inspecting the resulting service** ![host_service-disk_inspect1](https://community.icinga.com/uploads/default/original/1X/7601e5040e12036d66354cf9a539ea2d50b81d22.png) ![host_service-disk_inspect2](https://community.icinga.com/uploads/default/original/1X/f02058d17bb54339e58f02d2bfea63c49583f7fd.png) ![host_service-disk_inspect3](https://community.icinga.com/uploads/default/original/1X/85878a4ad8b0dfdbfdb621baa37edc50d97cd9d1.png) Thanks, Matthias Btw: I am a little bit lost in the middle of using “service-apply rules” which makes it harder to have different defaults (e.g. different thresholds) or “service-sets” where I can not iterate through host.vars…:-/ ---
**Author:** ![mdicss](https://community.icinga.com/letter_avatar_proxy/v4/letter/m/13edae/32.png) [@mdicss](https://community.icinga.com/u/mdicss)\ **Post date:** [May 3, 2021, 5:03pm UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/8 "2021-05-03T17:03:20Z")
Any news here? I sill have the same problem with director 1.8.0. Overrides are stored for the host but not for the applied services. The services still use the default values. ---
**Author:** ![blindzero](https://community.icinga.com/user_avatar/community.icinga.com/blindzero/32/134_2.png) [@blindzero](https://community.icinga.com/u/blindzero)\ **Post date:** [December 2, 2021, 7:44pm UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/9 "2021-12-02T19:44:22Z")
Unfortunately not and this turns out as one of the largest downsides in director for me ---
**Author:** ![log1c](https://community.icinga.com/user_avatar/community.icinga.com/log1c/32/2071_2.png) [@log1c](https://community.icinga.com/u/log1c)\ **Post date:** [December 3, 2021, 9:30am UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/10 "2021-12-03T09:30:43Z")
The problem is not the applied service but the “apply for”. There is a issue for this, but without any recent updates and it has been moved from milestone to milestone over the years. > > > I'm trying to override a service variable in the host to set a threshold for eac…h partition. > > The generated override only matches the Name of the Apply Rule - not the individual generated services of the apply rule - as you can't select the generated service I guess overriding apply for services isn't possible (yet)? > > \`\`\` > object Host "BAPM0" { > import "OurLinuxHost" > address = "172.31.15.43" > groups = \["linux", "sysE" \] > vars.disks = \["/home" \] > vars.\_override\_servicevars = { > "Disk Mountpoint " = { > disk\_crit = "5%" > } > } > } > \`\`\` > > Service Template + Apply For > \`\`\` > template Service "Disk Mountpoint" { > import "\[Template\] ssh-service (active)" > vars.by\_ssh\_command = "~/libexec/check\_disk.lin -w $disk\_warn$ -c $disk\_crit$ -p $disk$" > vars.disk\_crit = "10%" > vars.disk\_warn = "15%" > } > apply Service "Disk Mountpoint " for (config in host.vars.disks) { > import "Disk Mountpoint" > assign where "linux" in host.groups && host.name == "BAPM0" > vars.disk = config > import DirectorOverrideTemplate > } > \`\`\` > Cool would be to have the possibilty to create an override like this > \`\`\` > vars.\_override\_servicevars = { > "Disk Mountpoint /home" = { > disk\_crit = "5%" > } > } > \`\`\` > > I couldn't find any open bugreport regarding this. Overrides for “normal” applied services (coming from a single apply rule or a service set) work without problems ---
**Author:** ![twidhalm](https://community.icinga.com/user_avatar/community.icinga.com/twidhalm/32/18_2.png) [@twidhalm](https://community.icinga.com/u/twidhalm)\ **Post date:** [December 7, 2021, 1:28pm UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/11 "2021-12-07T13:28:34Z")
Director was never intended to offer more sophisticated features of Icinga. It’s focused on automatic syncs and for easy delegation to users who don’t know much about how Icinga 2 works. Director not having more complicated features implemented is on purpose. (Personally spoken) unfortunately there were some of the more complicated features implemented so we have now a mix of the easy to use GUI with some of the more powerful features. It was never intended to be a “GUI for Icinga” as far as I know. If you want things like `apply for`, use the DSL. Director is for easy to use and easy to understand features that require more typing and less knowledge. ---
**Author:** ![blindzero](https://community.icinga.com/user_avatar/community.icinga.com/blindzero/32/134_2.png) [@blindzero](https://community.icinga.com/u/blindzero)\ **Post date:** [December 8, 2021, 6:42am UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/12 "2021-12-08T06:42:24Z")
@twidhalm well thats a pitty, but the users have to respect the decision of the project. Nevertheless the project should think about the following - “market demand” why not delivering a feature which the “market” / “here users” ask for - communication: it is called “icingaweb2” what else should be expected than a web interface? Especially if the project’s pages state: “A lightweight and extensible web interface to keep an eye on your environment. Analyse problems and act on them.” If automation is the purpose: why offering the config parts at all? And why not calling it icingaautomate 😉 I also dont see why for recurring configurations users should use config file editing and for automation setup (less recurring) there should be a web interface… Sorry, but from product management perspective: doesnt make sense So IMHO a decision thats a pity as this kind is missing rrally and the foundations are there. ---
**Author:** ![twidhalm](https://community.icinga.com/user_avatar/community.icinga.com/twidhalm/32/18_2.png) [@twidhalm](https://community.icinga.com/u/twidhalm)\ **Post date:** [December 8, 2021, 8:54am UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/13 "2021-12-08T08:54:24Z")
There’s a little mixup in your post, @blindzero . 🙂 Of course “Icinga Web 2” is a web interface for Icinga 2. For _viewing_ and making minor changes like enableing or disabling notifications temporarly. What I meant is “Icinga Director is not a management GUI for Icinga that’s a full replacement for writing code in DSL”. Yes, there are many installations that only rely on Director to manage configuration but that includes missing out on many options you have when using DSL. If you prefer the easy way \ where you do a lot of configuration manually, that’s totally fine. But if you want to make use of all the power for easy and elegant configuration Icinga 2 has to offer, Director is the wrong tool. Director is great for automation. And it’s great for delegation. Say, you have a cople Icinga admins who really know the ins and outs of Icinga 2 and it’s configuration. They build a set of easy to use templates and offer other admins (usually Windows mouse-herders) with an easy to use interface. “Put the name of the host here, the IP address there and chose from the list of host types (referring to templates). The rest will be done automatically”. That’s where Director is big and shiny. Why not build a tool like that? The answer might be a bit religiously biased but you can’t build a GUI that’s as powerful as a configuration language. The only option would be to have big text fields where you enter Icinga DSL anyway. Everything else might be just too complex to build as a GUI. And even if it were possible - it’s always a matter of resources. And for your second point: Icinga Director offers automation that’s not available without Director at all. So it’s not about building a GUI for something you do only on rare occasions. Synchronizing config items from external sources is a feature you only get from Director. Director combines two parts in one tool: Sync from external sources (not available without Director but can be done by creating your own solution) and delegation (it’s basically doing the same as changing configuration files but in a waaaaay easier way) ---
**Author:** ![bamboo](https://community.icinga.com/user_avatar/community.icinga.com/bamboo/32/4190_2.png) [@bamboo](https://community.icinga.com/u/bamboo)\ **Post date:** [March 8, 2022, 4:34pm UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/14 "2022-03-08T16:34:43Z")
Just following up on this thread because I still can’t get the hang of with it these apply rules and property overrides. This was a showstopper back then when we first had a look at the director, the same issue seems to be there still. We currently doing the DSL way on the CLI which works totally fine but because of growing, more people without linux knowledge need to have access to the monitoring and make changes. Can anyone help me out how I can transform our current config into the director? ```auto apply Service for (win_service => config in host.vars.win_service) { import "default-service" check_command = "service-windows" command_endpoint = host.vars.remote_client vars += config display_name = win_service assign where host.vars.remote_client } ``` This is the simple apply for service we are running, on the host side we define the services like this: ```auto vars.win_service["Service 1"] = { service_win_service = "Service 1" } vars.win_service["Service 2"] = { service_win_service = "Service 2" } vars.win_service["Service 3"] = { service_win_service = "Service 3" service_win_warn = 1 } ``` So I need one service template to define all my services and custom thresholds. I saw the example in the docs but this doesn’t allow me to override e.g “service\_win\_service” Is it really the intention to create one service for each service, disk or process i want to monitor? ---
**Author:** ![Tqnsls](https://community.icinga.com/user_avatar/community.icinga.com/tqnsls/32/5067_2.png) [@Tqnsls](https://community.icinga.com/u/Tqnsls)\ **Post date:** [December 19, 2023, 2:37pm UTC](https://community.icinga.com/t/override-vars-not-working-for-service-applies/429/15 "2023-12-19T14:37:53Z")
> [@twidhalm](#): > > If you want things like `apply for`, use the DSL. Director is for easy to use and easy to understand features that require more typing and less knowledge Hi Thomas, are you intending to say that such “override”-features for an apply-for service is possible in the DSL? As far as I could test it in the DSL, I could not replicate the expected behavior as in OP’s first post. I could upload the small config I created for my test if you wish. Or is the “override”-feature for an apply-for service simply not implemented in the DSL yet?