icinga2_host vars doesnt support tuples

[dakota-marshall]

Hi there,

We have an Icinga host config that has tuples stored in the vars section of the host. When attempting to recreate this config using the icinga2 terraform provider, the plan errors out, as the vars seem to require a string.

Terraform Version

Terraform v1.5.5
on linux_amd64
+ provider registry.terraform.io/hashicorp/vsphere v2.2.0
+ provider registry.terraform.io/icinga/icinga2 v0.5.0

Affected Resource(s)

• icinga2_host

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

https://gist.github.com/dakota-marshall/657c7f2ea36491a39f733a02039fce53

Debug Output

https://gist.github.com/dakota-marshall/448d27e7e2e757eb4c382f2602e73c18

Expected Behavior

Plan passes correctly, allowing my to pass a tuple to the variables that require it

Actual Behavior

The plan fails, stating that the variables require a string, not a tuple

Inappropriate value for attribute "vars": element "automation_groups": string required.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform init
2. terraform plan

Important Factoids

Here is an example of what our Icinga Host object config looks like for reference

object Host "example" {
    import "my-host-template"
    address = "10.130.7.29"
    vars.os = "linux"
    vars.specialty = "linux"
    vars.department = "infrastructure"
    vars.priority = ["normal"]
    vars.level = 2
    vars.automation_groups = ["linux", "linux_infra_critical"]
    vars.ssl_uris = []
    vars.roles = []
    vars.checks = []
    vars.disabled_checks = []
}

[legioner0]

any updates or workarounds?

[legioner0]

any updates or workarounds?

Found workaround by myself - wrap tuples with jsonencode() in terraform manifest and then unwrap this data with Json.decode() in icinga configuration.

[dakota-marshall]

any updates or workarounds?

Found workaround by myself - wrap tuples with jsonencode() in terraform manifest and then unwrap this data with Json.decode() in icinga configuration.

Nice workaround!

I found the issue in the source, but it's also apparently an upstream issue as well. The function that creates hosts on the API was only allowing a map of strings, instead of an interface to allow for other types. Once that PR is submitted upstream I plan on creating a PR here to get it resolved on the provider, but that repo hasn't seen activity in 4 years, so I am not holding my breath....

Worse case scenario, I will probably fork this provider and use my forked version of the icinga2-api module so that I can start using it in projects.