I don't understand why this is confusing.
You have a service template that defines a timeperiod. All services
that use that template will inherit the notification_period value from
the template, if they don't specify a notification_period themselves.
By setting "notification_period null" in your service definition, you
are explicitly overriding all forms of inheritance and setting the
notification_period to null, which happens to be a special
notification_period.
So, the issue you are running into is due to you expecting implied
inheritance to take precedence over values defined in the service
definition itself. This would break the documented and expected
behavior of inheritance, and a lot of people's configurations.
Now, I understand how you could run into this issue. But take a look
at the documentation again:
>>> Quoting from the documentation:
>>>
>>> The following table lists the object variables that will be implicitly
>>> inherited from related objects if you don't explicitly specify their value
>>> in your object definition or inherit them from a template
The implied inheritance variables will only be inherited from related
objects, if they are not specified in either the object definition or
template. In your case, notification_period is defined in your
template, so the implied inheritance is already overridden. You can't
bring that back by also explicitly defining a notification_period in
your service definition, even if that happens to be null, as null is
also a valid value for notification_period.
Something that definitely would work is for you to define another
service template without a notification_period value, and use that for
checks you want implied inheritance from.
Something that might work, but unfortunately I can't try it as I've
already spent too much time on this email :-), is to set
notification_period to null in the template, which could mean that the
service definition will behave as though the notification_period value
is unset in the template. This would allow you to let the "null
notification period" template inherit from your normal template.
Best regards,
Martin Melin
On Wed, Dec 16, 2009 at 12:26 AM, Gordon Messmer <yiny...@eburg.com> wrote:
> On 12/15/2009 01:38 PM, Marc Powell wrote:
>> On Dec 15, 2009, at 2:04 PM, Gordon Messmer wrote:
>>
>>> Quoting from the documentation:
>>>
>>> The following table lists the object variables that will be implicitly
>>> inherited from related objects if you don't explicitly specify their value
>>> in your object definition or inherit them from a template
>>>
>>> ...so I need to not inherit the value from my template. How do I do that?
>>>
>> Don't specify the directive in the template.
>>
>
> Which means that I have to expand the template where I null-ify the
> notification period with the values from any of the templates it
> "uses". That seems like a minor inconvenience, but it's still uglier
> than it ought to be. When I do so, I still get the warning from "nagios
> -v". I'll test it to make sure that it's working.
>
>>> In some cases you may not want your host, service, or contact definitions
>>> to inherit values of string variables from the templates they reference. If
>>> this is the case, you can specify "null" (without quotes) as the value of
>>> the variable that you do not want to inherit.
>>>
>> You're mixing sections of the documentation to try to make a connection that
>> doesn't exist.
>
> If that's so, then at the very least the documentation should be updated
> to note that this won't work.
>
>> Again, specified with a value of 'null' does not equate to unspecified.
>> Looking at the code, if you specify the value in any way, including a value
>> of 'null', it breaks the implied inheritance.
>>
>> xodtemplate.h --
>>
>> #define XODTEMPLATE_NULL "null"
>>
>> xdata/xodtemplate.c --
>>
>> else if(!strcmp(variable,"notification_period")){
>> if(strcmp(value,XODTEMPLATE_NULL)){
>> if((temp_service->notification_period=(char
>> *)strdup(value))==NULL)
>> result=ERROR;
>> }
>> temp_service->have_notification_period=TRUE;
>> }
>>
>
> That sure looks like a bug to me. Even the indentation looks weird to
> me, is that the normal style? I can't imagine why "null" would be
> considered a valid notification period. If
> have_notification_period=TRUE were in the preceding block, the
> documentation would make more sense, and implied inheritance would be a
> lot easier to use. Do you think a patch to modify this behavior would
> be accepted?
>
> Thanks for the explanation. I appreciate your help.
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Nagios-users mailing list
> Nagios-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when reporting
> any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
