New feature: Mute when time is outside time_interval

[dubyte]

Currently mute_intervals allow to express the interval where the alarm won't be sent.
But would be useful to mute in the complement of the mute_time_interval.

Let's check at this example:

  routes:
  - receiver: devs
    mute_time_intervals:
      - offhours
      - holidays
    continue: true
  - receiver: monitoring
    active_time_intervals: 
      - offhours
      - holidays
  time_intervals:     
  - name: offhours
    time_intervals:
    - ...
  - name: holidays
    time_intervals:
    - ...

"mute_time_intervals" keyword to describe the intervals will be deprecated. Instead the configuration will use "time_intervals". When in a route there is active and mute time intervals, the mute_time_interval will have higher precedence.
For example:

 - receiver: group_a
    active_time_intervals:
    - officeHours
   mute_time_intervals:
   - lunchHour

Let's imagine that there is a time interval for officeHours 9am - 5pm and a lunch hour in the middle of the day. With this the alert will be sent during officeHours but it wont receive during the lunch.

Updated about:

• Deprecation of mute_time_interval
• new time_intervals config
• mute_time_interval has higher precedence than active_time_intervals

[benridley]

Nice @dubyte , I think this is a cool idea, and a natural extension of the time intervals concept so thanks for raising it. We should probably clarify the semantics of how this will work before considering further. Some of my rough thoughts:

• We should change the top level config section for mute_time_intervals to just time_intervals, while still allowing mute_time_intervals basically as an alias and note that its usage is deprecated.
• Mute time intervals will take precedence over active time intervals. This means that if a route provides both active and mute intervals, it will only be active during the active intervals unless that interval overlaps with a mute interval, in which case the route will be muted in the period of overlap.

Any thoughts?

[dubyte]

I agree about deprecating mute_time_interval.

About the precedence you mentioned, that is the current behavior of the PR but config is not mention it.

I can update the PR or what would be the next steps?

[dubyte]

Ahh i just noticed that I reference the PR #2779 but this is a comment in the New Feature "issue"
Should I update the new feature to include your comments and continue talking Frome there?

Thanks

[dubyte]

I updated the feature request to continue talking about this. Thanks

[simonpasquier]

Closed by #2779