Re: [Nagios-devel] RFC/RFP Service sets
Posted: Wed May 18, 2011 11:02 am
--90e6ba10ae3f52c1fc04a38ba8c1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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" wh=
at
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 allowe=
d,
>
> 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=B02 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 wit=
h
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 some
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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" wh=
at
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 allowe=
d,
>
> 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=B02 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 wit=
h
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 some
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]