RFC/RFP: Service parents

[Andreas Ericsson]

On 05/18/2011 04:37 PM, nap wrote:
> On Wed, May 18, 2011 at 3:23 PM, Andreas Ericsson<ae at op5.se>  wrote:
> 
>>   [...]
>> Nested definitions would be neat, but it's a tad weird that you
>> favour the un-nested service sets while arguing for other objects.
>>
>> I try to use existing one to be more complete for the use property than
> create new ones if we can avoid it ;)
> 
>>
>> Based on ~250 nagios configurations, I've verified that 99.67% of
>> all servicedependencies are created to suppress notifications when
>> the agent goes offline. In that case, parents will do just fine
>> for this very, very, very common case.
>>
> But so we should look at why users are not using it fot other interesting
> cases, like don't notify (I think we are all ok to say only the notification
> options are really useful) for a webservice if the database is down or such
> other "logical" stuff that we've got now we all N tiers applications?
> Is that just useless, or is it just too hard to define? I don' have as much
> installation that you, but I think this can be very, very useful.
> 
> 
>>
>>
>>>> [..]
>>
>> With just one parent/dependency in the common case, there's very
>> little reason to care about whether the logic is an OR or an AND.
>> Quite simply put; I want to make it exceedingly easy for basic
>> users to get very useful functionality without having to learn
>> about service dependencies. Dependencies and escalations fall into
>> the "complex" category which the average user evaluating Nagios
>> has no clue about.
>>
> Yes, it's complex, but the "parent" is the same logic to explain after all?
> It's just a matter of syntax if we allow user to do more or not. We can
> still explain them with simple example like local agent dependency.
> 
>>
>>>
>>> [...]
>>
>> Ignore templates. Most object parameter shouldn't even have to be
>> defined, and Nagios should provide sensible defaults for everything
>> except object identifier and actions on state-changes. That would
>> make templates more or less redundant for everything besides altering
>> defaults.
>>
>   Yes, we do not have to change a lot of things in most of the cases. The
> main activity is :
> * define how the host element is checked, warn X contacts and do not warn if
> X is already down.
> * link N services with it. And we got the same need as hosts for services
> (how to check, warn X contacts and not if others elements are already dead)
> 
> It's all what we are talking about, and templates help user to do not define
> all theses property again and again. In a perfect world, you just need to
> "describe" the host and all is done (so host AND services). So the question
> is : is there one or more way to "describe" ?
> 

Overloading templates in a non-obvious manner causes confusion. Adding a
new type for it is perfectly legitimate imo.

>>
>>> We should add very few "host elements" to the service. Like if the host
>> is
>>> an Oracle server, who need to have the information "this server got PROD,
>>> QUAL and DEV base"? It's not a service that is an external element from
>> this
>>> host, but the host element itself.
>>
>> Huh? Where does host elements get added to the service?
>>
> 
>>> That where I like the duplicate_foreach property we use in shinken that
>> came
>>> from one of your idea from self-contained elements (can be resumed in
>> "for
>>> each host property you create a service") : all host data are in the
>> host.
>>>
>>
>> Agreed. I'll most likely do something similar for service sets,
>> although they'll be added as arguments to the service sets so
>> it'll look something like this (thinking loosely):
>>
>> define host {
>>         host_name oracle-on-windows
>>         service_sets    oracle(databases=foo,bar,xyzzy),windows(disks=C-E)
>> }
>>
>> Final format is nowhere near complete though.
>>
> Yes, it's the same idea here (host get data, not services). It's just you do
> not give parameters to sets, just as classic _macros that will be used for
> services creation.
> 
>>
>>> And here the service_dependencies is just like this : the service is the
>>> element that "got" this dependency after all. Yes add a "parent" with
>> less
>>> "power" than true dependency is possible, but why not kill two birds with
>> a
>>> unique stone?
>>
>> Because it's more complicated. Adding something with 100 points of
>> value that 20% of all users understand and use is worth 1/3 as much
>> as adding something with 60 points of value that 100% of all users
>> understand and find useful.
>>
>> Or perhaps I just don't understand you.
>>
> If nearly all users are using dep for bad agent notification disable, your
> version if more simple, so better.
> But if users are not using dep because it's too complex for
> not-the-same-host configuration, it's not optimal.
> 

No, it's not optimal, but it's simple and useful. Optimal would be
if all users knew how to use the very powerful dependencies we have
in Nagios today, but that's not going to happen anytime soon. Judging
by the votes and ideas on ideas.nagios.org and the notes and issues
at tracker.nagios.org, it also matches what people want.

>>
>> Others have suggested those ideas though, and I have no idea how
>> to implement it sanely yet, but letting services have parents and
>> unifying how the two objects are handled in many of the API's have
>> more benefits than just this one feature.
>>
> But I don't see how the parents definition will handle the both objects?
> It's true that get a unique dependency tree management can be far more easy
> to parse on run for sending or not notifications ;)
> 

Neither do I, but that's for a different day, really. I know how to
handle it internally, but not how to represent it sanely in config.

-- 
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