RFC/RFP Service sets

[Andreas Ericsson]

On 05/18/2011 02:02 PM, nap wrote:
> 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.
> 

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

Very true.

> But with
> it you can use the same "service" in several sets,

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.

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

Except that templates now serve two different purposes, which has *already*
proven to be confusing to people.

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

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.

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