<br><br><div class="gmail_quote">On Wed, May 18, 2011 at 3:23 PM, Andreas Ericsson <span dir="ltr"><<a href="mailto:ae@op5.se">ae@op5.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"> [...]<br>
</div>Nested definitions would be neat, but it's a tad weird that you<br>
favour the un-nested service sets while arguing for other objects.<br>
<div class="im"><br></div></blockquote><div>I try to use existing one to be more complete for the use property than create new ones if we can avoid it ;)<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
<br>
</div>Based on ~250 nagios configurations, I've verified that 99.67% of<br>
all servicedependencies are created to suppress notifications when<br>
the agent goes offline. In that case, parents will do just fine<br>
for this very, very, very common case.<br></blockquote><div>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?<br>
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.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
<br>
>>[..]<br>
<br>
</div>With just one parent/dependency in the common case, there's very<br>
little reason to care about whether the logic is an OR or an AND.<br>
Quite simply put; I want to make it exceedingly easy for basic<br>
users to get very useful functionality without having to learn<br>
about service dependencies. Dependencies and escalations fall into<br>
the "complex" category which the average user evaluating Nagios<br>
has no clue about.<br></blockquote><div>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
><br>
> [...]<br>
<br>
</div>Ignore templates. Most object parameter shouldn't even have to be<br>
defined, and Nagios should provide sensible defaults for everything<br>
except object identifier and actions on state-changes. That would<br>
make templates more or less redundant for everything besides altering<br>
defaults.<br></blockquote><div> Yes, we do not have to change a lot of things in most of the cases. The main activity is :<br>* define how the host element is checked, warn X contacts and do not warn if X is already down.<br>
* 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)<br><br>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" ?<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> We should add very few "host elements" to the service. Like if the host is<br>
> an Oracle server, who need to have the information "this server got PROD,<br>
> QUAL and DEV base"? It's not a service that is an external element from this<br>
> host, but the host element itself.<br>
<br>
</div>Huh? Where does host elements get added to the service?<br></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> That where I like the duplicate_foreach property we use in shinken that came<br>
> from one of your idea from self-contained elements (can be resumed in "for<br>
> each host property you create a service") : all host data are in the host.<br>
><br>
<br>
</div>Agreed. I'll most likely do something similar for service sets,<br>
although they'll be added as arguments to the service sets so<br>
it'll look something like this (thinking loosely):<br>
<br>
define host {<br>
host_name oracle-on-windows<br>
service_sets oracle(databases=foo,bar,xyzzy),windows(disks=C-E)<br>
}<br>
<br>
Final format is nowhere near complete though.<br></blockquote><div>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> And here the service_dependencies is just like this : the service is the<br>
> element that "got" this dependency after all. Yes add a "parent" with less<br>
> "power" than true dependency is possible, but why not kill two birds with a<br>
> unique stone?<br>
<br>
</div>Because it's more complicated. Adding something with 100 points of<br>
value that 20% of all users understand and use is worth 1/3 as much<br>
as adding something with 60 points of value that 100% of all users<br>
understand and find useful.<br>
<br>
Or perhaps I just don't understand you.<br></blockquote><div>If nearly all users are using dep for bad agent notification disable, your version if more simple, so better.<br>But if users are not using dep because it's too complex for not-the-same-host configuration, it's not optimal.<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"> It solve hard service dependency definition (99% of the case<br>
> do not need a specific timeperiod or specific options) and solve your parent<br>
> behavior that is in the end a dependency (don't cry if a nrpe services based<br>
> is critical and the nrpe agent is down).<br>
> I think people hate service dep not because it's too hard to understand<br>
> (it's a AND when parents are an OR, quite simple :) ), but because it's a<br>
> nightmare to configure in a large environment and that can't be used with<br>
> templates.<br>
><br>
<br>
</div>Try explaining the difference between AND and OR to someone who's<br>
never intended to add more than one element anyway and he'll just<br>
consider you crazy.<br></blockquote><div>Yes, if he just need one agent case, he just don't care :)<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> The only problematic point is to have a service parent of an host (and with<br>
> both definitions if I'm not wrong), but I've got problem to find a case<br>
> where it's useful in fact.<br>
><br>
<br>
</div>When you have a virtual switch with multiple addresses and you want<br>
a specific port on one service to be the parent of the host connected<br>
to that particular port, for instance. Or when you want a service on a<br>
virtualization server to be the parent of a hostcheck.<br></blockquote><div>If I understand the first one, I use business process elements to get such a dependent host, then use classic parents with this host.<br><br>For the second, it's true that the only way from now if to get the virtualization server host check as this service check and not a classic ping check, then use host dep it's true.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Others have suggested those ideas though, and I have no idea how<br>
to implement it sanely yet, but letting services have parents and<br>
unifying how the two objects are handled in many of the API's have<br>
more benefits than just this one feature.<br></blockquote><div>But I don't see how the parents definition will handle the both objects?<br>It's true that get a unique dependency tree management can be far more easy to parse on run for sending or not notifications ;)<br>
<br><br>Jean<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Andreas Ericsson <a href="mailto:andreas.ericsson@op5.se">andreas.ericsson@op5.se</a><br>
OP5 AB <a href="http://www.op5.se" target="_blank">www.op5.se</a><br>
Tel: <a href="tel:%2B46%208-230225" value="+468230225">+46 8-230225</a> Fax: <a href="tel:%2B46%208-230231" value="+468230231">+46 8-230231</a><br><br></div></div></blockquote></div>