RFC/RFP Service sets

nap naparuba at gmail.com
Wed May 18 14:02:06 CEST 2011


On Wed, May 18, 2011 at 12:04 PM, Andreas Ericsson <ae at op5.se> wrote:

> 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:
> >
> >
>
> Because overloading objects to mean many different things is a
> concept that confuses users and therefore sucks arse.
>
> But I think we just push the template logic. When you want to "define" what
an host is, you define how it's checked and who is notified. I think it's
more logicial to explain to a user than if it's a linux server that got an
Oracle database it should be use Linux,Oracle than Linux and then add a new
property for al Oracle stuff. Admins don't care about hosts and services,
it's just a matter of internal dependencies.

It will be easier for them to add contacts of Oracle admins in the same
template that define Oracle services than to add it in the first host
template or a new one you need to add in the end. (maybe I'm not clear
here...)



> > 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.
>
That why I think it's more logical to gave all "properties" of an host in
the same "use" property. It hide a level of complexity (host property vs
service one) to users that don't have to manage all of this. They just want
simple service sets, not to understand all Nagios internals. For them, the
same object should allow to add windows contacts and windows services. If
you separate the host property than the service it will be linked too, it
will be just more complex for them.


>
> > 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.
>
I talk about service template on host templates, not service over service
that is hopefully allowed :)

>
> > 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.
>
I thought about managing, linking, checking, etc the new object than just
parsing it, but if it's easy, it's not a problem so.


>
> > 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.
>
I don't understand this, can you give me an example? Is it that when you
want to remove such an set you just need to do it in one 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.
>
I think it's a bit more hard to "see" what is in the set it's true. But with
it you can use the same "service" in several sets, and will be easier for
admins that configure hosts because they just need to add templates and do
not need to understand what is in it (the nagios admin can add contacts and
services in this set, or just contacts or just sets, it's not something the
host configuration admin need to know).

I think "standard admins" are using more time to add new hosts than the
nagios admin use to add new sets and manage all his template. If we want to
help the most users, we should help "host configuration" admins first that
do not understand all that they do, but just want a windows server with all
classic service that the nagios admin prepared and the good contacts in the
same way.


Jean


>
> --
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20110518/512bd67e/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
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
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel


More information about the Developers mailing list