<br><br><div class="gmail_quote">On Wed, May 18, 2011 at 11:50 AM, 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>
<br>
</div>Because it makes it possible to unify the logic between hosts<br>
and services in the long run, which will enable us to let a<br>
service be a parent of a host. Some people have requested that,<br>
and with service-dependencies it becomes quite difficult unless<br>
we overload those objects too. There's too much overloading in<br>
Nagios today, which leads to user confusion and addon-tool<br>
complexity that simply shouldn't be there.<br></blockquote><div>Hi,<br><br>Yes, but I think service dep are to complex just because they are external objects that apply on other objects, and not objects that can be called or defined nested in host or service. Just like you say a bit later with self-containted objects. <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>
> For "same host" we can take let a void host_name for same host for example.<br>
> So it will be easy to define same host dependencies, and even external ones.<br>
><br>
<br>
</div>That's already supported, and people still think it's too complicated.<br>
Parents is a familiar concept that people understand already.<br></blockquote><div>But it's not the same logic. Parents for hosts are an OR, when dependencies are an AND. Will be hard to explain that the same property got different behavior is you define it on an host or a service. Or if you just want to use it as a single object link (nrpe with nrpe and nothing else). <br>
<br>But this will not solve dependencies problem (too much difficult to define an object for each link, it's just a nightmare) when the service_dependencies can solve both.<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>
> We add this in Shinken, it helps a lot too for managing large configuration<br>
> (dep can be managed with templates with such an option).<br>
><br>
<br>
</div>Then you'd need separate templates for agent-based services and<br>
standard network-based ones. I prefer the "parents" directive.<br></blockquote><div>It's just an OR or AND relationship after all that make logical and network relation different. If the logic is different, we should not give the same name, or use this parent for service as an OR, but it make less sense for a service than for an host I think.<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;">
<br>
One (large) problem of Nagios today is that very few objects are<br>
self-contained if you want to maintain a proper configuration. A<br>
service is mentioned in as many as 10-12 different places and all<br>
of them have to be modified to get rid of the service or change<br>
its name. The long-term goal of making simple things easy and<br>
complex things possible starts with making objects more and more<br>
self-contained, and then adding exceptions for the rare and<br>
complex cases.<br></blockquote><div>It's so true that why we should propose a way so ALL (or at least the maximum) options are available through templates, so when you define an host, you can define it in a global way with no more service or other elements definition.<br>
<br>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. <br>
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.<br>
<br>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? It solve hard service dependency definition (99% of the case do not need a specific timeperiod or specific options) and solve your parent behavior that is in the end a dependency (don't cry if a nrpe services based is critical and the nrpe agent is down). <br>
I think people hate service dep not because it's too hard to understand (it's a AND when parents are an OR, quite simple :) ), but because it's a nightmare to configure in a large environment and that can't be used with templates.<br>
<br>The only problematic point is to have a service parent of an host (and with both definitions if I'm not wrong), but I've got problem to find a case where it's useful in fact.<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 class="im">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><div></div><div class="h5">Considering the successes of the wars on alcohol, poverty, drugs and<br>
terror, I think we should give some serious thought to declaring war<br>
on peace.<br>
</div></div></blockquote></div><br>