how to unset a custom property

[rgevaert]

How can one unset a property through an override?

In our service I configured a default value for a specifiek custom property. Now for one host I need to unset that value. I don't see any way how it can be done.

The specific example is regarding a service that uses the check_http command.

I set http_auth_pair to nagios:somepass in the service definition. There are custom fields so I can override it for specific services. That works. But unsetting it isn't possible on the service instance for a specific host.

[dbu1986]

Following up here, since I also often get into this situation. I have to exclude specific hosts in some service apply rules and create individual services, just because most of the hosts need the custom variable and a few don't.

Is there any best practice regarding a service apply strategy?

Some ideas to unset an inherited custom variable value:

• inserting some macro variable like $null$ (I'm not sure if it would get processed if inserted as a string in the input field)
• providing a checkbox right to input fields having inherited values, for "resetting" the value to (null)

[Thomas-Gelf]

These are two different questions. @dbu1986, what you're asking for exists since Director 1.5. Just go to as Hosts Services tab, see all applied services, choose the one you do not like and click Blacklist. @rgevaert: what you're looking for isn't possible, at least not yet. When wiping a field you'll inherit what the template defines. There are two possible workarounds: a) blacklist the inherited Service, add an individual one. b) design your templates differently / use more templates (like "HTTP Check" and "Unauthenticated HTTP Check")

[Thomas-Gelf]

@dbu1986: sorry, I misread your comment. You're describing the same problem/requirement as @rgevaert does. As I said, that's not possible right now, you already mentioned one possible workaround.

A way to solve this would be the possibility to explicitly set null for a variable, via some dedicated Checkbox/link/button. Of course only for fields where the required flag has not been set.

[dbu1986]

nvm, thanks for your quick reply and btw your awesome work! I would highly appreciate such a feature, since we have lots of cases in which we need to use this workaround.

[rgevaert]

Thanks for the feedback and labeling it as enhancement Thomas!

[kosli]

This would really be great as e.g. some of the commands/templates that are installed by default have variables set in the template and I would like to use the template, but cannot use it as long as the variables are set.

e.g. ipmi-sensor assumes that the check is run over the network and sets accordingly the parameters, whereas i am running it locally on the host itself, which is not possible as long as the values are set and cannot be "unset"

[araujorm]

This would really be great as e.g. some of the commands/templates that are installed by default have variables set in the template and I would like to use the template, but cannot use it as long as the variables are set.

e.g. ipmi-sensor assumes that the check is run over the network and sets accordingly the parameters, whereas i am running it locally on the host itself, which is not possible as long as the values are set and cannot be "unset"

Confirmed. ipmi-sensor is quite crippled with icinga director in most of our use cases at the moment, without the possibility to unset inherited values. The only alternative is to clone the command definition with a different name and unset the defaults, which is quite cumbersome...

[jeredfloyd]

I came here with the same question, and found that setting the property to an undefined variable has the desired effect, e.g. "$null$".

[araujorm]

I came here with the same question, and found that setting the property to an undefined variable has the desired effect, e.g. "$null$".

That's brilliant, thanks for sharing :) I guess this closes the issue, no?

[araujorm]

I came here with the same question, and found that setting the property to an undefined variable has the desired effect, e.g. "$null$".

That's brilliant, thanks for sharing :) I guess this closes the issue, no?

Sorry, my first tests weren't correct. This does not work exactly as intended... what it does is set the value to an empty string, not to an undefined value.

For example, the "procs" command that comes with the icinga2 ITL. It predefines vars.procs_warning to 250, causing -w 250 to always be appended. But in a lot of cases what I want is just to check if a specific process is running so what I want is to set -c 1: and -w should not be on the argument list. With icinga DSL I can just set vars.procs_warning = null on the service definition and I'm set.

In director we can't do that, and the aforementioned workaround just sets vars.procs_warning to an empty string '', making -w '' to be appended to the plugin argument list... it ends up working because this particular plugin treats '' as an empty value, but that's not always the case :(

So I guess the issue can't be closed yet.

But if $null$ was treated specially by director, it could be an easy to implement solution, no? What do you thing @Thomas-Gelf ?

Edit: fixed example above and a few typos