allow multiple *Writer objects of the same type

[lesinigo]

Icinga2 has support for multiple GraphiteWriter / InfluxdbWriter / *Writer config objects out of the box, but puppet-icinga2 versions >= 1.3.1 make it impossible to configure them without resorting to use resources external to the module.

Expected Behavior

I'd like to be able to configure two InfluxdbWriter objects, or two GraphiteWriter objects, and so on. It is a rare use case but it's good to be able to use it when you want it.

Current Behavior

puppet-icinga2 does not have explicit support for more than one *Writer object, but up to and including version 1.3.0 it was possible to hack them up as ::icinga2::object resources, like this:

icinga2::object { "InfluxdbWriter_1":
  object_type => 'InfluxdbWriter',
  object_name => 'InfluxdbWriter_1',
  attrs       => $writer_config_1,
  target      => '/etc/icinga2/features-available/influxdb.conf',
  notify      => Class['::icinga2::service'],
}
icinga2::object { "InfluxdbWriter_2":
  object_type => 'InfluxdbWriter',
  object_name => 'InfluxdbWriter_2',
  attrs       => $writer_config_2,
  target      => '/etc/icinga2/features-available/influxdb.conf',
  notify      => Class['::icinga2::service'],
}

Possible Solution

A possible solution would be to convert icinga2::feature::influxdb to be defined resources instead of classes. The common use case of just one writer per type should be mostly / completely unaffected but it would allow to define more than one.

Context

We are implementing Icinga2 in a big organization that demands two independent copies of everything whenever possible, and we are also using open-source InfluxDB that wouldn't support clustering anyway.

Using puppet-icinga2 v1.3.0 we define two InfluxdbWriter objects just like the above example and that allows us to meet the requirement.

Your Environment

• Module version: icinga-icinga2 (v1.3.0), currently cannot upgrade due to this issue
• Puppet version: 4.10.8
• Operating System and version: various, mostly CentOS 7

[lbetz]

We implemented all feature in class to manage the files in features-available. The common use is that you declare every object of a feature once. For special setups we prefer the way you used. We will not replace the feature class with a defined resource. But maybe we can add a dedicated object defined resource like icinga2::object::influxdbwriter?

[lesinigo]

Having something in the module to be able to handle special cases is a good idea. Simple things should be simple, complex things should be possible :)

I would have thought about letting users actually access icinga2::object because that is the single most generic resource... why not removing assert_private() from that one and just stating clearly in the documentation that is should be used only "if you know what you are doing" and/or that its API shouldn't be considered stable (if that is the reason why it was marked private)?

[lbetz]

Now finally the decision to allow special configuration only with the help of icinga2::config::fragment.