Is there a descriptive explanation of apply somewhere?

Hi there,

I’m using the puppet module which maybe makes this a little harder to understand but I don’t think so in this case.

Is there a full description somewhere of what apply the following actually means and how it fits in? I’m expecting the answer to be pretty long winded as it’s not obvious. (I’ve taken the code from https://github.com/Icinga/puppet-icinga2/tree/master/examples/example4)

Manifest code:

  ::icinga2::object::service { 'linux_disks':
    import           => ['generic-service'],
    apply            => 'disk_name => config in host.vars.disks',
    check_command    => 'disk',
    command_endpoint => 'host.name',
    vars             => 'vars + config',
    assign           => ['host.vars.os == Linux'],
    ignore           => ['host.vars.noagent'],
    target           => '/etc/icinga2/zones.d/global-templates/services.conf',
  }

Hiera data for host variables:

---
icinga2::host:
  vars:
    os: Linux
    disks:
      'disk /':
        disk_partition: /

Hi @rick_pri

Maybe this document can help here. Or are you explicitly looking for an explanation for your example?

Hi,

I’m explicitly trying to understand why I might get something like:

Error: Error while evaluating expression: Operator + cannot be applied to values of type ‘String’ and ‘Dictionary’
Location: in /usr/local/etc/icinga2/conf.d/services.conf: 61:3-61:16
/usr/local/etc/icinga2/conf.d/services.conf(59): check_command = “http”
/usr/local/etc/icinga2/conf.d/services.conf(60): zone = “master”
/usr/local/etc/icinga2/conf.d/services.conf(61): vars += config

When I have something like:

apply         => 'http_check => config in host.vars.custom_checks',

and then some hiera like:

  test-lb:
    vars:
      custom_checks:
        https:
          http_address: "%{lookup('icinga2::custom_hosts.test-lb.address')}"
          http_vhost: "%{lookup('icinga2::custom_hosts.test-lb.address')}"
          http_uri: '/wp_login/'
          http_sni: 'true'
          http_ssl: 'true'
          http_ssl_force_tlsv1_or_higher: 'true'
          http_verbose: 'true'
        http:
          http_address: "%{lookup('icinga2::custom_hosts.test-lb.address')}"
          http_vhost: "%{lookup('icinga2::custom_hosts.test-lb.address')}"
          http_uri: '/wp_login/'
        cert_check:
          http_address: "%{lookup('icinga2::custom_hosts.test-lb.address')}"
          http_vhost: "%{lookup('icinga2::custom_hosts.test-lb.address')}"
          http_sni: 'true'
          http_ssl: 'true'
          http_ssl_force_tlsv1_or_higher: 'true'
          http_certificate: '28' # Number of days that a cert must be valid for

This works, but incorrectly, it only applies the very final values (the ones for the cert_check). However, if I change apply to like follows for example:

apply         => 'http_check => config in host.vars.custom_checks.http',

Then I will get the error message quoted at the beginning of this message complaining about merging a string and a dictionary object. So what I need to understand is this weird syntax for apply.

I’m going to try to break it down. config in host.vars.custom_checks will loop over each key? So is will be:

[{'https': {'http_address': '...', etc.}}, {'http': {}}, {'cert_check': {}}]

But then I don’t understand the http_check => bit, it looks a little like JS/Ruby syntax, JS for an arrow function and Ruby whatever the hash rocket thing is.


Some time later …

Okay, and here it is. I needed to add a stub inbetween so that I could do this.

My apply line as I tried out earlier:

apply         => 'http_check => config in host.vars.custom_checks.http',

But this time I’ve had to add a key called vars so that the http_check can iterate over the http, like this:

  test-lb:
    vars:
      custom_checks:
        https:
          vars:
            http_address: "%{lookup('icinga2::custom_hosts.test-lb.address')}"
            http_vhost: "%{lookup('icinga2::custom_hosts.test-lb.address')}"
            http_uri: '/wp_login/'
            http_sni: 'true'
            http_ssl: 'true'
            http_ssl_force_tlsv1_or_higher: 'true'
            http_verbose: 'true'
        http:
          vars:
            http_address: "%{lookup('icinga2::custom_hosts.test-lb.address')}"
            http_vhost: "%{lookup('icinga2::custom_hosts.test-lb.address')}"
            http_uri: '/wp_login/'
        cert_check:
          vars:
            http_address: "%{lookup('icinga2::custom_hosts.test-lb.address')}"
            http_vhost: "%{lookup('icinga2::custom_hosts.test-lb.address')}"
            http_sni: 'true'
            http_ssl: 'true'
            http_ssl_force_tlsv1_or_higher: 'true'
            http_certificate: '28' # Number of days that a cert must be valid for

This is definitely something that needs documenting and explaining pretty much everywhere so that it’s understandable.