[dev.icinga.com #11976] Assign for

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/11976

Created by friesoft on 2016-06-17 17:13:36 +00:00

Assignee: tgelf
Status: Resolved (closed on 2016-10-31 20:38:05 +00:00)
Target Version: 1.2.0
Last Update: 2016-10-31 20:38:05 +00:00 (in Redmine)

---

We are migrating from Nagios to Icinga(web)2 with Director and are trying to do as much as possible through Director to keep the configuration in one place and make it easy for everyone to edit it.

Assign for is a feature we would need to make use of the data we are importing into our hosts.

Example Host (imported/synced using Director):
object Host "MyHost" {
import "OurHost"
address = "1.1.1.1"
vars.tomcats = [
"/opt/tomcat",
"/opt/tomcat2"
]
}

Example Service (currently handcrafted in the config):
apply Service "Tomcat " for (tomcat in host.vars.tomcats) {
import "[Template] ssh-service (active)"
vars.by_ssh_command = "/opt/nagios/libexec/check_proc -C java -a '" + tomcat + "' -c 1:1"
assign where host.vars.tomcats
}

Are assign for rules already planned for the near future?

Changesets

2016-10-21 13:33:49 +00:00 by cardeois f645bf4

Add support for Apply for rules in services

Apply for rules are defined through `apply_for` property
Only Array custom variables will be eligible in apply_for dropdown.

API Example:
```bash
 ./director-curl POST director/service?name=my_service '{"apply_for": "for (checked_tcp_port in host.vars.checked_tcp_ports)" }'
 ```

 Will render as:
 ```
  apply Service "my_service" for (checked_tcp_port in host.vars.checked_tcp_ports) {
      ...
  }
  ```
Feature: https://dev.icinga.org/issues/11976

Depends-On: https://github.com/Icinga/icingaweb2-module-director/pull/20
refs #11976

2016-10-21 13:33:49 +00:00 by cardeois 6e20f36

Use `config` variable in apply for rules

* use `config` instead of `value` in apply for rules
* update documentation

refs #11976

2016-10-21 19:11:57 +00:00 by cardeois 66e0bce

Add support for Apply for rules in services

Apply for rules are defined through `apply_for` property
Only Array custom variables will be eligible in apply_for dropdown.

API Example:
```bash
 ./director-curl POST director/service?name=my_service '{"apply_for": "for (checked_tcp_port in host.vars.checked_tcp_ports)" }'
 ```

 Will render as:
 ```
  apply Service "my_service" for (checked_tcp_port in host.vars.checked_tcp_ports) {
      ...
  }
  ```
Feature: https://dev.icinga.org/issues/11976

Depends-On: https://github.com/Icinga/icingaweb2-module-director/pull/20
refs #11976

2016-10-21 19:11:57 +00:00 by cardeois 32e4787

Use `config` variable in apply for rules

* use `config` instead of `value` in apply for rules
* update documentation

refs #11976

2016-10-22 00:15:09 +00:00 by (unknown) bcef87f

Add support for expressions

Any rendered string can contain variables encapsulated with "$$" characters.

Example:
Display Name declared with `Port $$host.vars.tcp_port$$ check` will
be processed as `"Port " + host.vars.tcp_port + " check"`

API:
```bash
 ./director-curl POST director/service?name=my_service '{"display_name": "Port $$host.vars.tcp_port$$ check" }'
 ```

 Rendered config:
 ```
  apply Service "my_service" {
      import "my_template"

      display_name = "Port " + host.vars.tcp_port + " check"
  }
 ```

refs #11976

2016-10-22 00:15:09 +00:00 by cardeois ddcfb09

Handle expressions only for apply objects

Expressions will be handled only if the object is an ApplyRule.
Only properties and custom variables are replaced.

refs #11976

2016-10-22 00:15:09 +00:00 by cardeois 37c9105

Expressions syntax is now $var$

Instead of $$var$$.
We make sure $$var$$ is left untouched.

refs #11976

2016-10-22 06:00:54 +00:00 by cardeois e7bd434

Add support for Apply for rules in services

Apply for rules are defined through `apply_for` property
Only Array custom variables will be eligible in apply_for dropdown.

API Example:
```bash
 ./director-curl POST director/service?name=my_service '{"apply_for": "for (checked_tcp_port in host.vars.checked_tcp_ports)" }'
 ```

 Will render as:
 ```
  apply Service "my_service" for (checked_tcp_port in host.vars.checked_tcp_ports) {
      ...
  }
  ```
Feature: https://dev.icinga.org/issues/11976

Depends-On: https://github.com/Icinga/icingaweb2-module-director/pull/20
refs #11976

2016-10-22 06:07:57 +00:00 by cardeois 3e30d34

Use `config` variable in apply for rules

* use `config` instead of `value` in apply for rules
* update documentation

refs #11976

[icinga-migration]

Updated by tgelf on 2016-06-17 19:44:08 +00:00

Time ago I was planning an Assign for implementation for Director and then stopped doing so as for users working with the GUI only there is no benefit in using "apply for" over "adding single services to the host". However, it would help people doing automation, importing hosts with a bunch of custom vars.

As apply for rules easily tend to get pretty complicated I had however no good idea on how to offer them in the GUI. I worked with customers doing exactly what you want, they where happy with imported structured vars (no related fields required as long as you do not want to modify them in the GUI) combined with hand-crafted apply rules shipped with the "fileshipper" module through Director.

However, once more and more teams desired to work with that environments, this week something new has been designed and already mostly implemented (not committed yet). The new requirements where:

• I want to use apply for to create services based on host properties
• I want to define related custom in the very same Dictionary
• I still want to be able override all or some of those vars in the GUI (e.g. warning/critical thresholds)
• I do not want consecutive sync runs to destroy those manual changes while still importing changes to other related vars

The involved components could look as follows for your example:

// template prepared in Director:
template Service "Tomcat Process Check" {
  import "Generidc Service"
  check_command = "by_ssh"
  vars.by_ssh_command = "/opt/nagios/libexec/check_proc -C java -a '$tomcat_path$' -c 1:1" 
  vars.tomcat_path = "/opt/tomcat"
}

// Imported Host:
object Host "MyHost" {

   vars._magic = {
     "Tomcat Process Instance 1" = { "templates" = "tomcat" }
     "Tomcat Process Instance 2" = {
        "templates" = "tomcat"
        "vars" = { "tomcat_path" = "/opt/tomcat2" }
     }
   }
}

I intentionally modified your example, defined a default path and worked differently in Instance 1 and Instance 2. Just to show you it's possibilities. When you define fields for tomcat_path on the command or service template you would be allowed to override it for every instance directly in the services tab of each host. Makes sense as soon as you want the threshold (process count ecc) to be configurable.

Please let me know whether such thing could help you or how it could be improved to better fit your needs.

Thanks,
Thomas

NB: You'll find better by_ssh example on the web, it is possible to create args looking like "real" argument structures in your vars.

[icinga-migration]

Updated by friesoft on 2016-06-17 20:21:01 +00:00

To be honest I don't fully get it yet. Where does the "templates" = "tomcat" come from? Or did you just pick a wrong name for the template definition?
How can such a host be generated using director? I haven't succeeded in creating dictionaries yet :(

Another usecase for us is something like this:
@object Host "MyHost" {
......
vars.vhosts["search3.xxxx.at:80"] = {
http_address = "111.111.111.111"
http_port = "80"
http_vhost = "search3.xxxx.at"
http_ignore_body = true
http_onredirect = "sticky"
http_extendedperfdata = true
}
vars.vhosts["search3.xxxx.at:443"] = {
http_address = "111.111.111.111"
http_port = "443"
http_ssl = true
http_vhost = "search3.xxxx.at"
http_ignore_body = true
http_onredirect = "sticky"
http_extendedperfdata = true
}
}

apply Service "http-" for (vhost => vhost_config in host.vars.vhosts) {
import "generic-service"
check_command = "http"
vars += vhost_config
notes = "HTTP checks for " + vhost
assign where host.vars.vhosts
}
@
If something like this can be generated using director using your solution we would be really happy and it would be one step further to getting rid of manually editing config files :)

Thank you really much for your dedication and help! :)

[icinga-migration]

Updated by msmol on 2016-08-03 20:53:45 +00:00

+1

My team (jprivard + cardeois) and I are actively working on this. We have the API part mostly done (missing tests). We still have yet to start working on the GUI bits however.

Work so far can be seen here (with an example in the commit message): internap@753f984

For the API we do not currently validate the given "apply_for" rule. That is to say if you enter an invalid rule, that API will not complain, but the deployment will fail.

This feature, in order to be usable depends on the "$variable$" notation given above by tgelf. We currently have our own hacked solution (using the ` character instead of $) but will there be an official implementation for this feature?

[icinga-migration]

Updated by tgelf on 2016-08-03 22:23:18 +00:00

msmol wrote:

My team (jprivard + cardeois) and I are actively working on this. We have the API part mostly done (missing tests). We still have yet to start working on the GUI bits however.

Cool!

Work so far can be seen here (with an example in the commit message): internap@753f984

Looks good to me at first sight. Love that you moved blacklistedProperties out of the function. Could you please name them propertiesNotForRendering or similar and push this as a separate commit? I'd immediately merge it, would allow me to get rid of quite some redundant render-functions.

For the API we do not currently validate the given "apply_for" rule. That is to say if you enter an invalid rule, that API will not complain, but the deployment will fail.

I do not like this part. What about storing only the variable name in the apply_for column, checked_tcp_ports in your case? The variable names used in the loop could be hardcoded and always the same. That way it could easily be validated.

This feature, in order to be usable depends on the "$variable$" notation given above by tgelf. We currently have our own hacked solution (using the ` character instead of $) but will there be an official implementation for this feature?

We could use $variable$ as this is the Icinga 2 way of placing macros into properties. They are not allowed in display_name and similar, but we could hack around this with the generated apply rule based on the macro() function. Please have a look at this apply for, it currently makes part of an experimental feature:

https://github.com/Icinga/icingaweb2-module-director/blob/master/library/Director/IcingaConfig/IcingaConfig.php#L468

I'd have no problem with dynamically generating something more complex like this for every genereated "apply for" construct.

Cheers,
Thomas

[icinga-migration]

Updated by cardeois on 2016-08-31 21:30:15 +00:00

I've create a pull request introducing apply rules for services: #23
However this PR depends on #20 () where the decision is not taken yet about how we would handle the "value" object in the for loop.

[icinga-migration]

Updated by friesoft on 2016-10-31 16:38:14 +00:00

Anything missing here? I haven't been able to test the latest master yet but as far as I've seen the related pull requests are merged? :)

[icinga-migration]

Updated by tgelf on 2016-10-31 20:37:52 +00:00

• Status changed from New to Assigned
• Assigned to set to tgelf
• Target Version set to 1.2.0

That's true, this is in the current master and works fine - thanks for pointing me to this open issue.

[icinga-migration]

Updated by tgelf on 2016-10-31 20:38:05 +00:00

• Status changed from Assigned to Resolved