servicegroup_name in serviceescalation limited by hostgroups

[Andreas Ericsson]

Fraser Scott wrote:
> 2008/9/6 Andreas Ericsson <ae at op5.se>:
>> A lot, and the result would be one which users would have to scratch
>> their heads quite a while before they understood it properly, especially
>> when taking '!foo' into account as well.
> 
> While that is true, I wouldn't have though that in this case there
> would be that much risk. I would like to be at a stage where I can
> easily create a host like
> 
> define host {
>     use           distributed-host,important-host,base-server
>     name       host1
>     blah....
> }
> 
> define service {
>     use           distributed-service,important-service,base-service
>     host_name                    host1
>     service_description       SSH
>     blah....
> }
> 
> distributed-host and distributed-service defines whether things like
> check_freshness/notifications are on etc.
> 
> Because we know SSH on host1 is an important service on an import
> host, we know what the contact_group will be (escalation-team) and
> that they will get an SMS. A standard service on the important host
> could, for example, only receive an email.
> 
> Using service escalations we can also specify that a standard service
> on an important host gets an SMS sent out on the 5th notification.
> However, all of this does assume I can do something like:
> 
> serviceescalation {
>      hostgroup_name      important-hosts
>      servicegroup_name  standard-services
>      contact_groups         standard-team,escalated-team
>      first_notification        5
>      last_notification        0
> }
> 
> Using the host/service templates, hosts automatically become members
> of the correct groups as do services. Other group memberships are
> specified inside the host/service group using the members variable.
> 
>> There are limits to how much free-style should be allowed when editing
>> the configuration.
> 
> Whilst it is free-style, it is still fairly elegant. Also, to randomly
> force servicegroups to be applied to all hosts seems a bit arbitrary.
> 
>> At some point the semantics of what one is editing is
>> no longer clear and it would simply have been faster for the user to
>> add two objects rather than look up exactly what's happening when they
>> use config voodoo hack A27C36. What you're proposing fits rather nicely
>> into that "over-clever semantics" group, imo.
> 
> But that is what good documentation is for. Anyway, as I explained
> above (hopefully) this method actually simplifies things for any
> further administrators of the system, unless they want to look under
> the hood, in which case they consult the docs.
> 
> Any other thoughts on this would be welcomed.
> 

I can't exactly remember what the original issue was and I'm far
too tired to read it just now, but as usual I'll review and test
any patches sent to this list.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/