servicegroup_name in serviceescalation limited by hostgroups

[Fraser Scott]

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.

-Fraser

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