RFC/RFP Service sets

[nap]

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

> On 05/18/2011 02:02 PM, nap wrote:
>  [...]
>
> You're sort of missing the point. Consider service sets as "service
> templates with added services", but with a much clearer syntax and a
> less muddied explanation than what you're proposing. To be honest, I'm
> not sure exactly what it is you ARE proposing, and neither are any of
> my colleagues. That's a sort of point in favour of my suggestion, I'd
> say.
>
The idea was to have a "service set" but with current defined elements and a
unique property for all host description properties (so use "use" :) ).

> Or just add them as a global variable (template-style) to the service
> sets they want to use. Perhaps you missed that part of the example I
> posted.
>
> Yes it seems so.

> [...]
>
> I disagree. It's a shame that "use" is already taken, but perhaps we
> can let "profiles" be a duplicate of "service_sets" in the host object.
> I suspect that's really the only remaining point of this discussion,
> along with the fact that "use" can't be abused (teehee) to let hosts
> link to service templates as well.
>
> But do understand that the nested-compound style service sets will, in
> fact, *be* a special kind of service template with linked-in services
> that hosts can reference.
>
Yes, the only point is how we describe host in fact. I prefer got a unique
property for all hosts "things" (how we check it, who we notify, what
service we add in).


> [..]
>
> But then you're forbidding host templates from having the same name
> as service templates, which is currently allowed. Not a very senible
> limitation, imo.
>
I don't think so, the link is done with the host_name propery for services
templates (if it's a template, it will look for host template, that's the
main idea).


> [..]
>
> That's totally trivial. The nested-compound version is a bit easier
> since less stashed data needs to be used, but with a sensible 2-pass
> config parser even that could be avoided.
>
I always see parsing more difficult that it is so :)

>
> [..]
>
> Consider this (for non-nested version); Some admin on a site where
> they only use MySQL creates a service set named "db-services" and
> ships it upline so others can reuse it. In order to rename it
> (with non-nested version, ofcourse), other people who wants to use
> it have to rename it in not only the service_set "name" parameter
> but also in each and every service shipped with the service set.
>
> And please don't tell me users are sensible. We know that's not
> always true, and the few that aren't add grief and suffering to
> those who are. Always have and always will.
>
True. So the name visibility can be a problem indeed.

[..]
>
> Why would you want to? PING should probably be on (very nearly) all hosts,
> while all webserver type checks should only be on all hosts that have a
> webserver. It's true that the basic HTTP check will have to be in the set
> for both apache and MS(whateveritsnameis) servers, but that's still a huge
> improvement over how it works today, and once admins start sharing their
> service sets it won't really matter, because checks for one type of server
> will all be contained in the service set.
>
 Just to get again a gain the most little configuration as possible ;)
But maybe this time it is just too much.

>
> [..]
>
> Except that templates now serve two different purposes, which has *already*
> proven to be confusing to people.
>
I try to explain to my colleges how to configure a new host and it's always
hard to explain that we've got templates for some properties and some other
one for services (was groups, now it's sets with a level less for link it's
true). They just don't understand the host/service point, and just want to
ear about host and "it's a Windows, so I put the windows template and I'm
done".

>
> [..]
>
> Object configuration inheritance will still work more or less the
> same as they do today, so contacts etc will be inherited from the
> host for the services that don't have any. That and the ability to
> optionally customize service set parameters from their inclusion
> in the host makes me very certain I'm doing this right.
>
> Yes, if we keep the implicit inheritance for this object, will do the trick
:)

We can have the template thing with sets, but we will need to explain admins
the "addition inheritance" so, but maybe it's the easier way and split
description in two properties (your solution so)?


Jean


> --
> Andreas Ericsson                   andreas.ericsson at op5.se
> OP5 AB                             www.op5.se
> Tel: +46 8-230225                  Fax: +46 8-230231
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20110518/bfce5db0/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