ScheduledDowntime objects should support Time Zones

[philomory]

Similar to #5374, but a distinct request insofar as ScheduledDowntime objects are not defined in terms of TimePeriod objects.

I'd like to see something like the following:

object Host "myhost" {
  ...
  vars = {
    time_zone = 'Pacific/Honolulu' // tz database zone name
    opening = "08:00"
    closing = "16:00"
  }
}

apply ScheduledDowntime "local-business-hours" to Host {
  ranges = {
    "monday - friday" = "00:00-" + host.vars.opening +  "," + host.vars.closing + "-24:00"
    "saturday - sunday" = "00:00-24:00"
  }
  time_zone = host.vars.time_zone
  assign where "business_hours_only" in host.groups
}

Expected Behavior

Downtimes are calculated in the specified timezone, allowing the same apply rule to be used for all devices globally.

Current Behavior

Downtime is scheduled at the specified times in UTC (or whatever the server timezone is).

You could attempt to emulate the desired by specifying opening and closing in UTC, but given the lack of support for ranges that cross midnight, as well as the lack of library functions for manipulating time range specifications, this becomes untenable once you get beyond a certain UTC offset. For instance, the above example in Pacific/Honolulu time would need to be translated to:

ranges = {
  "monday" = "00:00-18:00"
  "tuesday - friday" = "04:00-18:00"
  "saturday" = "04:00-24:00"
  "sunday" = "00:00-24:00"
}

This is hard to work out in your head (I'm not even sure I got it correct), Icinga doesn't provide the sort of library functions that would be necessary to calculate it automatically.

Possible Solution

The ability for ScheduledDowntime objects to include TimeZones in their definition would help address this issue. Providing library functions for manipulating range specifications would be a possible alternative solution; ideally, it'd be great to have both.

Context

We have systems we need to monitor in sites around the globe. Some of these systems are always-on, but many of them must be shut down at the end of (local) business hours. Worse, not all locations in a given time zone keep the same office hours. Manually managing 100+ scheduled downtime definitions is untenable; so far we've not come up with a good solution.

Your Environment

• Version used (icinga2 --version):
  Application information:
  Installation root: /usr
  Sysconf directory: /etc
  Run directory: /run
  Local state directory: /var
  Package data directory: /usr/share/icinga2
  State path: /var/lib/icinga2/icinga2.state
  Modified attributes path: /var/lib/icinga2/modified-attributes.conf
  Objects path: /var/cache/icinga2/icinga2.debug
  Vars path: /var/cache/icinga2/icinga2.vars
  PID path: /run/icinga2/icinga2.pid

  System information:
  Platform: CentOS Linux
  Platform version: 7 (Core)
  Kernel: Linux
  Kernel version: 3.10.0-693.5.2.el7.x86_64
  Architecture: x86_64

  Build information:
  Compiler: GNU 4.8.5
  Build host: unknown

• Operating System and version: Centos 7 (mostly 7.4.1708)

• Enabled features (icinga2 feature list):
  Disabled features: command compatlog debuglog elasticsearch gelf graphite influxdb livestatus opentsdb perfdata statusdata syslog
  Enabled features: api checker ido-pgsql mainlog notification

• Icinga Web 2 version and modules (System - About):
  Icinga Web 2 Version: 2.5.0
  Git commit: ebe1917b152b786cc708abe5215fd0c4be7c4237
  Git commit date: 2017-11-27
  director: 1.4.2
  fileshipper: 1.0.1
  monitoring: 2.5.0
  puppetdb: 1.0.0

• If you run multiple Icinga 2 instances, the zones.conf file (or icinga2 object list --type Endpoint and icinga2 object list --type Zone) from all affected nodes.
  We do, but I don't think including 100+ copies of zones.conf would be helpful given that this issue isn't about zone config.

[Crunsher]

This depends on #5374

As soon as TimePeriods support Timezones, timezones work with everything.

[philomory]

I note that this issue has been given the tag "needs-sponsoring" (as has #5374). What does that actually mean in this project? Contributing.md doesn't actually mention sponsorship at all.

[Crunsher]

You can reach out here if you/your company wishes to sponsor a feature. In an issue context needs-sponsoring generally means "This would be nice to have, but it's currently not on the roadmap".

There is no enterprise version of Icinga 2 so all of these sponsored issues end up in the free Icinga release.

[dnsmichi]

I'm not a friend adding another feature to the buggy ScheduledDowntime object implementation, we should at first decide what to do with existing bugs and then decide whether we want to add more features onto it.

The hint with contributing and sponsoring is good, I will take a note on updating this accordingly, thanks.

[dnsmichi]

Blocked by #7288.

[julianbrost]

Implementing this would require looking into how this could be done consistently across platforms, so this could potentially require using/shipping (on Windows) a custom library/timezone database.

However, this is probably not only a feature request. Currently, each node locally evaluates these time ranges locally using the local timezone information. So if a cluster is spread across timezones, this can lead to inconsistent times for the same object across the cluster. So allowing to set the timezone would also allow fixing that problem.