RFC/RFP: Service parents

[Andreas Ericsson]

On 05/17/2011 02:47 PM, nap wrote:
> On Tue, May 17, 2011 at 9:57 AM, Andreas Ericsson<ae at op5.se>  wrote:
>> [...]
>>> Comments and patches welcome.
>>>
>>> --
>>> Andreas Ericsson                   andreas.ericsson at op5.se
>>> OP5 AB                             www.op5.se
>>> Tel: +46 8-230225                  Fax: +46 8-230231
>>>
>>
> Hi,
> 
> Why not add a "service_dependencies" property for services (that take ,
> separated host/service_description list) so we can configure services
> dependencies as easily as parent for hosts? It will auto-generate a
> service_dependency for each elements with standard options (24x7 period, bad
> states for notifications).
> 
> With true service_dep objects, we won't have problem for managing all cases
> of inheritance, it's already done. It's just "configuration sugar".
> 

Because it makes it possible to unify the logic between hosts
and services in the long run, which will enable us to let a
service be a parent of a host. Some people have requested that,
and with service-dependencies it becomes quite difficult unless
we overload those objects too. There's too much overloading in
Nagios today, which leads to user confusion and addon-tool
complexity that simply shouldn't be there.

> For "same host" we can take let a void host_name for same host for example.
> So it will be easy to define same host dependencies, and even external ones.
> 

That's already supported, and people still think it's too complicated.
Parents is a familiar concept that people understand already.

> We add this in Shinken, it helps a lot too for managing large configuration
> (dep can be managed with templates with such an option).
> 

Then you'd need separate templates for agent-based services and
standard network-based ones. I prefer the "parents" directive.

One (large) problem of Nagios today is that very few objects are
self-contained if you want to maintain a proper configuration. A
service is mentioned in as many as 10-12 different places and all
of them have to be modified to get rid of the service or change
its name. The long-term goal of making simple things easy and
complex things possible starts with making objects more and more
self-contained, and then adding exceptions for the rare and
complex cases.

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