RFC/RFP Service sets

[Andreas Ericsson]

On 05/17/2011 02:41 PM, nap wrote:
> On Tue, May 17, 2011 at 2:27 PM, Andreas Ericsson<ae at op5.se>  wrote:
> 
>> Ahoy (again).
>> [... service sets]
>>
> 
> Hi,
> 
> Why not use a "service template on host template" feature instead? The idea
> is near the second one you proposed. If you add an host_name to a service
> that is a template, it will generate such service for all hosts that will
> use this template. So when all your services are defined and lined in the
> good host templates you will defined :
> 
> define host {
>     use Linux, Oracle, WhatEver
> }
> 

Because overloading objects to mean many different things is a
concept that confuses users and therefore sucks arse.

> And the Linux, Oracle, WhatEver are regular host templates, with some
> services templates linked for each of them. It's more natural for users to
> think about "templates" than to use a new property. So for example the Linux
> template will add linux admins as contacts and will add all Linux standard
> services checks (/, /var, memory, swap,...).
> 

Not really. You're considering users that are already very
familiar with Nagios. I'm considering the ones that have no
clue what so ever.

> We already got all elements we need (template on template is not allowed,

template on template *is* allowed. I have no idea what gave you the
notion it's not, but a service-template can use another template
just fine.

> it will be easier for
> configuration tools than a new object.

I doubt it. Hacking in code in Nacoma to handle nested compounds
took all of 35 minutes.

> It will be just like your solution
> N°2 a little more hard to exchange such "sets" (but in the sample
> configuration we can just put a configuration file by sets for example).
> 

With the added problem that the service set name is horribly
denormalized and has to be printed on everything that gets attached
to it as well as everything that uses it, when it really should only
ever be printed at the sites that use it so objects can be safely
removed without leaving leftovers all over the place.

> It's what we add in Shinken, and it work quite well :)
> 

I'll have to look at a sample of that someday I think. It sounds
terribly confusing, whereas service sets as nested compounds sounds
very, very simple to understand. Noone I've explained them to have
asked about the value of them or how they work, at least.

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