Feature Enhancement Request: Services ARGs should be able to override template values, even if it is specified as blank in the template

[ne-lgute]

This request is from eloyd in the Support Forum

Imagine a command (call it check_eric) that does this:

$USER1$/check_dummy $ARG1 $ARG2

Now imagine a service template (call it st_eric) that does this:

command: check_eric
ARG1: 0
ARG2: <blank>

Lastly, imagine a service that:

use st_eric
ARG1: <blank>
ARG2: This is my ARG2

ARG2 from the service will never be used because ARG2 from the template is blank. So even though a "more specific" setting is in the service description, it is ignored because it's using a template.

This is not consistent with other template settings.

We'd like to see the arguments (or the command, actually) allowed to be overridden at the service level even if a template has some of them specified. This would make for a much more powerful templating system.
[GL:XI#1268]

[tsadpbb]

I don't know if this entirely fits what you are looking for but you can accomplish this with custom macros

define command {
    command_name    check_arg_macro
    command_line    $USER1$/check_dummy $_HOSTARG1$ $_HOSTARG2$
}

define host {
    host_name               templatehst
    name                    templatehst
    address                 localhost
    max_check_attempts      2
    check_period            24x7
    notification_period     24x7
    contact_groups          admins
    check_command           check_arg_macro
    check_interval          1
    _ARG1                   0
    _ARG2                   Good
    register                0
}

define host {
    host_name hst3
    use templatehst
    _ARG1 2
}

define host {
    host_name hst2
    use templatehst
    _ARG2 TEST
}

[ericloyd]

Trying to avoid doing wonky things like that. The assumption is that things specified in the service definition override things in the template. But templates that have blanks in the argument fields don't get their arguments overwritten by the service. Would love to see that straightforward logic implemented.

[tsadpbb]

Are you specifically referring to the ARG macros? Currently, you can't set them like with what you provided, you get an invalid configuration error. Are you wanting the ability to specify the ARGn values in the configuration in addition to being able to set them in the check_command argument? Which one should take precedence in the instance that both are specified?

[ericloyd]

Read the original post.

[tsadpbb]

I did. I guess I'm just a big dumb dumb because I'm confused. Correct me if I'm wrong but you can't currently specify the command arguments in the object definition in the way you specified in the original post. Do you want this ability added with the the normal templating rules applied to it?

Is this XI specific and you are referring to setting these values in the CCM? Like you want

define host {
    host_name               templatehst
    name                    templatehst
    check_command           check_dummy!!Good
    register                0
}

define host {
    host_name hst2
    use templatehst
    check_command          check_dummy!2!
}

To be equivalent to

define host {
    host_name               templatehst
    name                    templatehst
    check_command           check_dummy!!Good
    register                0
}

define host {
    host_name hst2
    use templatehst
    check_command          check_dummy!2!Good
}

[ericloyd]

Yes, I know you can't do what I want to do. That's why it's an Enhancement request! 😉

[tsadpbb]

Yes, I know you can't do what I want to do. That's why it's an Enhancement request! 😉

Just trying to get the specifics

[ericloyd]

Here. This is what I would like to see:

TEMPLATE has check_command and arg1 specified but not arg2. arg2 is blank (as are all other args).
SERVICE inherits TEMPLATE and leaves check_command and arg1 blank but specifies arg2 as "foobar"

As it stands now, this is invalid and the command will be "check_command arg1" without arg2. I'd like to see it execute as "check_command arg1 arg2" since the more-specific service definition has an arg2 specified even though the inherited template does not.

This is the behavior for everything else (if the template leaves something blank but the service defines it, then it's defined).

[tsadpbb]

Okay so if a service has the same check command as it's template, then it will also inherit any unspecified args

[tsadpbb]

For example, the following config

define host {
    host_name               templatehst
    name                    templatehst
    check_command           check_dummy!0
    register                0
}

define host {
    host_name hst2
    use templatehst
    check_command          check_dummy!!Test
}

Would be equivalent to

define host {
    host_name               templatehst
    name                    templatehst
    check_command           check_dummy!0
    register                0
}

define host {
    host_name hst2
    use templatehst
    check_command          check_dummy!0!Test
}

[ericloyd]

No. In pseudo code:

Command_Definition:
command_line: check_dummy ARG1 ARG2

Template:
check_command: Command_Definition
ARG1: six
ARG2:

Service:
inherit: Template
ARG1: blank
ARG2: blue

The resulting command should be:
check_dummy six blue

[ericloyd]

Whoops. I see I cross-posted. I think we're saying the same thing now, yes.

[tsadpbb]

Alright, I think I got it, in the event that someone does

define host {
    host_name               templatehst
    name                    templatehst
    check_command           check_dummy!0!Test
    ARG1                    2
    ARG2                    Override
    register                0
}

Which should take precedence, the values specified in the check command or the values specified via the ARGn parameters?

[tsadpbb]

I would assume the ARGn parameters

[ericloyd]

I just realized we might be talking about two different things here, slightly. This wasn't supposed to be a Nagios Core request, it was Naigos XI. The XI GUI doesn't allow the operation I'm requesting and no one is manipulating check_command directly; it's being built from elements of the UI.

I believe that changes how this conversation goes slightly, but in the end, if the service/host definition says "check_command check_dummy!!test" and the template says "check_command check-dummy!six" then the resulting check_command should be "check_dummy!six!test"

I'm thinking that my original request was misinterpreted as a Nagios core issue, when I believe it's an XI one.