RFC/RFP: Service parents

[Andreas Ericsson]

On 05/17/2011 02:14 PM, lists wrote:
> You can probally ask these questions your self but...
> If my understanding of this is correct, How will this work in a
> templated environment?
> eg Will the parent service be configured via a hostname / service name pair
> Or just a service name, that Nagios will look on the applied host to find?
> (I ask as we use host templates to apply service to hosts).
> 
> I am probably being very anal here, would this situation work?
> Host
>      |
>       - service0 NRPE -->
>                    -- service1 App check1
>                    -- service2 App check2
>      |
>       - service3 HTTP check1
>       - service4 HTTP check2
> 
> Could we have "HTTP check1" depend on "App check1" but not "NRPE"?
> 

Yes, but if NRPE is a real parent (ie, a binary check to see that
the agent is running), there's no way it will fail without also
making App check1 failing.

A bigger question though is why you'd want to. If something serves
the proper html page over the network, does it really matter to you
if App checkX is working?

> eg NRPE dies so service1 alerts are suppressed, but "service3" will
> alert if needed.
>      But if "App check1" fails (but not NRPE) "HTTP check1" will not alert?

I should think so, but that depends on how we decide to implement it.
A service that returns OK when its parent has returned non-OK is
obviously misconfigured (since it really shouldn't be ok with a non-OK
parent), but there's no real reason to dive deeper than a single level
for parenting checks. We can just let users shoot themselves in the
foot with misconfigured parent chains and ignore all multi-depth
traversals completely.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay