[dev.icinga.com #10804] Impossible to use a for-loop variable into apply service vars

[icinga-migration]

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

Created by nerzhul on 2015-12-09 13:25:44 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-05-10 21:55:55 +00:00 (in Redmine)

---

Hello
This module is great but there is a big limitation in the vars processing due to the processing of the vars in the apply_service part.

Here is the thing i want to do (hiera form)

icinga::apply_service:
  'disk':
    template_to_import: "generic-service"
    check_command: "check_remote_disk"
    assign_where: "host.vars.disk_crit && host.vars.disk_warn"
    apply: "for (mount_path in host.vars.mounts)"
    display_name: "Partition \" + mount_path + \""
    vars:
      mount_path: "mount_path"

mount_path is correctly handled in the display_name by escaping from double-quotes but in the vars hashmap it's impossible to escape from double-quotes.

Here is the result into icinga2

apply Service "disk" for (mount_path in host.vars.mounts) {
      import "generic-service"
  display_name = "Partition " + mount_path + ""
  assign where host.vars.disk_crit && host.vars.disk_warn 
  check_command = "check_remote_disk"
  vars += {
    "mount_path" = "mount_path"
  }
  enable_notifications = true
}

If i try to escape here is the new result

apply Service "disk" for (mount_path in host.vars.mounts) {
      import "generic-service"
  display_name = "Partition " + mount_path + ""
  assign where host.vars.disk_crit && host.vars.disk_warn 
  check_command = "check_remote_disk"
  vars += {
    "mount_path" = "\\\"mount_path\\"
  }
  enable_notifications = true
}

What i expect is:

apply Service "disk" for (mount_path in host.vars.mounts) {
      import "generic-service"
  display_name = "Partition " + mount_path + ""
  assign where host.vars.disk_crit && host.vars.disk_warn 
  check_command = "check_remote_disk"
  vars += {
    "mount_path" = mount_path
  }
  enable_notifications = true
}

The problem is due to the function which dumps the vars argument in lib/utils.rb

The interest here is to use a mounts variable (collected by facter and set to host) and generate sensors using NRPE argument. And mount_path is not available in checkCommand if i don't add it to vars in the applyService.

[icinga-migration]

Updated by nerzhul on 2015-12-10 14:37:22 +00:00

I propose the following patch

voxpupuli/puppet-icinga2#162

If we add %@@ as a tag on the string the string is not parsed it's sent as raw string, permitting to use icinga2 variables instead of dumping variables to string

[icinga-migration]

Updated by buzzdeee on 2016-02-11 21:37:21 +00:00

I also struggle about this problem, I have this in applys/disk.conf:

apply Service "disk" for (disk => config in host.vars.disks) {
import "generic-service"
display_name = "disk"
assign where host.vars.os "Linux" || host.vars.os "OpenBSD"
check_command = "disk"
vars += {
"config" = {
}
}
enable_notifications = true
}

That is OK so far, and

what I want to generate in hosts/foo.conf:

vars += {
disks["disk"] = {}
"os" = "OpenBSD"
}

but I get:

vars += {
"disks[\"disk\"]" = {
}
"os" = "OpenBSD"
}

PR 162 was rejected, maybe there is a different way to achieve the same?

[icinga-migration]

Updated by dagobert on 2016-03-12 16:52:31 +00:00

I am implementing many apply for rules right now by creating a file in conf.d because I am also struggling with this problem.

In my opinion the easiest way would be to create a separate object for this purpose that is handling the variables differently to the existing. Trying to put too much logic into the erb template will make it too complicated, I think.

[icinga-migration]

Updated by VisionFhg on 2016-04-29 09:58:54 +00:00

Yes, PR162 wasn't the cleanest solution, be we need a way to accomplish this.

Right now, we are doing it like this:

::icinga2::object::apply_service { 'backupage':
    templates              => ['onceaday-service'],
    display_name      => 'Backupage',
    apply                       => 'for (identifier => backup in host.vars.services.backup)',
    check_command => 'vision-backupage',
     custom_append => [
         'vars += backup',
        ],
}

And then, using a custom check-command to access the custom variable like this: value => '"$HIERA_KEY$"',

[icinga-migration]

Updated by buzzdeee on 2016-05-10 21:55:55 +00:00

the custom_append helped me into the right direction.

It allowed me to refer to a hosts.vars.blah_blah variable of
a objects/hosts/....conf file for some other test.

With regard to the disk enumeration that I mentioned in my
prior comment, I had to figure that the object/host.pp class
doesn't have such custom_append/custom_prepend like the
object/apply_service.pp class.
That made me add this like done here:
voxpupuli/puppet-icinga2#208

with that, I can get around the limitation in the puppet module,
and create such a for loop as I like.