Implement conditional statements/loops parameter for icinga2::object::*

[baurmatt]

Expected Behavior

puppet-icinga2 allows to add a Service like this:

apply Service "vhost " for (vhost => config in host.vars.http_vhosts) {
  host_name = "localhost"

  check_command = "http"

  if (config.interval) {
    check_interval = config.interval
  } else {
    check_interval = 5m
  }

  assign where host.vars.http_vhosts
}

The important part for us is the if () {} else {} part

Current Behavior

Its currently not possible to add conditional statements/loops by using the icinga2::object::* classes

Possible Solution

Due to the (could be) complex nature of conditional statements/loops I suggest to only add a custom parameter to the icinga2::object::* classes which allows to add free text to an object.

Steps to Reproduce (for bugs)

Try to add a conditional statements/loops with icinga2::object::* classes.

Your Environment

• Module version (puppet module list): Forked master with enhancements
• Puppet version (puppet -V): 4.10.1
• Operating System and version: Ubuntu 16.04

[lbetz]

How the module should know at what position the custom snippet has to be added?

[baurmatt]

Not sure yet :( The best solution would probably be something like the concat::fragment order parameter but this is surely really hard to implement. Perhaps we just try it after import?

[lbetz]

That's not stable. What will be done if you wanna use attribute set by the same object?

[baurmatt]

Not sure what you mean, sorry. Can you give an example please?

[lazyfrosch]

Conditional statements require context and order.

At the moment the object config is rendered from a Hash, where the order doesn't matter.

We could offer a custom_code string field. But still, the best way should be to handle special cases via a separate config file. (out of scope of icinga2::object)

[lbetz]

In my opinion this should be the only way.

…

Am 30.08.2017 um 15:41 schrieb Markus Frosch ***@***.***>: Conditional statements require context and order. At the moment the object config is rendered from a Hash, where the order doesn't matter. We could offer a custom_code string field. But still, the best way should be to handle special cases via a separate config file. (out of scope of icinga2::object) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#354 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEDqLdgaffkP8RoS56cO-SgGHaayM3V6ks5sdWaegaJpZM4O6Tvi>.

[baurmatt]

custom(_code) would be fine with me. I definitely prefer it over a custom made icinga2::config::fragment because i can use all the object.conf.erb logic.

[lbetz]

No you can't, lazyfrosch explained it.

[bobapple]

We had this discussion many times over the time. It does not make sense for us to add this kind of complexity to the module. I think even these complex types of configuration are already covered in an acceptable way. I'll close this issue since we had this topic for many times now, thank you for your effort.