> On Wed, May 18, 2011 at 12:04 PM, Andreas Ericsson wrote:
>
>> On 05/17/2011 02:41 PM, nap wrote:
>>> On Tue, May 17, 2011 at 2:27 PM, Andreas Ericsson 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 litt
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]