naparuba/shinken — pull request #981 by geektophe (2013-08-22 17:42:28+00:00)
Title: Added service instance properties override feature

This patch introduces the new `serviceoverride` object, which allows to to override specific service instances properties.

Currently, It is possible to adapt commands to specific host settings through macros defined at host or service level. But there is no way to customize services attributes for particular hosts when they are dynamically generated through template linking (such as services defined in packs), or hostgroups.

**Example**

Imagine a mysql cluster which you monitor various parameters, including slave replication lag. You decide to use the `mysql` pack to build your configuration, which introduces a bunch of cool service checks.

But in that cluster, one host is used to perform tasks that stop replication at fixed time periods, and you don't want to be alerted for this particular host when replication lag climbs (it's normal). The perfect solution for that is to use a *maintenance period*.

If you use the `mysql` pack, you may consider setting the maintenance period on this particular service, but it's a template: it would be set up for all the hosts composing your cluster, which is not what you want. Or you could set a void maintenance period on all services from the pack, and make the particular host use the maintenance period you defined at host level, but if the node crashes, you would not be alerted at all, which is still not what you want.

One way to solve this problem is to **not** use the `mysql` pack for this host, and manually **re define** the various services from the pack for this host.

Another way is to use the new `servciceoveride` parameter to overload the maintenance period of this particular host.

Here's a config sample representing mysql hosts named `dbserver-XX`, and the worker named `dbworker-01` which you want to define a `maintenance_period` for `Slave lag` service.

; a standard host
define host {
host_name dbserver-01
use ...,mysql,...
...
}
... ; other standard hosts

; the special host (defined as normal host)
define host {
host_name dbworker-01
use ...,mysql,...
...
}

; sets maintenance_period named dbwork only for the Slave lag service associated to dbworker-01
define serviceoverride {
host_name dbworker-01
service_description Slave lag
maintenance_period dbwork
}

**Implementation**

This is mainly useful for dynamically generated services such as those linked to host templates (those defined in packs for instances), or linked to hostgroups. This allows to override a specific instance parameters without having to define a
complete new service.

The new `serviceoverride` object may be configured exactly as a `service` would be: it uses the same attributes. The `host_name` and `service_description` parameters are mandatory, as they are used to identify the service instance to overload parameters. The only parameters that may not be overloaded are `servicegroups` and all triggers
related parameters because they are linked during the `explode` phase, and `use`.

Overloading is performed in the arbiter's `load_config_file` method. Only the attributes explicitly set on the `serviceoverride` object (excepted those mentioned above) are set on the corresponding service instance. At the moment the attributes are overloaded, they are only strings: it is done before the `pythonize` and `linkify` operations are executed. The substitution does not interfere with object linking as links are done later.

As they are only useful during the configuration phase, once they have done their job, `serviceoverride` objects are trashed (as of templates, for instance).