[dev.icinga.com #9235] in_notification_period for notification objects

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/9235

Created by ddegois on 2015-05-07 07:54:46 +00:00

Assignee: (none)
Status: Closed (closed on 2015-11-10 09:03:17 +00:00)
Target Version: (none)
Last Update: 2015-11-10 09:03:17 +00:00 (in Redmine)

---

Would it be possible, if [Feature #9231] is implemented to retroport it also on Icinga 1.x CGIs ?

D.

---

Relations:

• duplicates #9235

[icinga-migration]

Updated by ricardo on 2015-05-07 09:16:43 +00:00

• Status changed from New to Feedback
• Assigned to deleted ricardo

Hi,

just checked it. This is not possible without a lot of pain.

We would have to copy paste quite a bit of code just to present this one line.

But you could do it as well. Witch would cause a lot of pain on your side.

You can request the config of all hosts, services and timeperiodes as json and determine the notification state based on this data. And you have to request this data only if the "program_start" timestamp has changed.

Would this help you?

Cheers
Ricardo

[icinga-migration]

Updated by ddegois on 2015-05-07 09:52:29 +00:00

And all this wihout even considering time zones ...
Too bad.

I think I'll pass on this one :D

Regards,
Damien

[icinga-migration]

Updated by mfriedrich on 2015-05-07 10:46:18 +00:00

in_notification_period is not a core status item which will cause plenty of changes inside the core, interfaces and compatibility. I think that's qualified for an Icinga 2 API, but not 1.x legacy interfaces. Livestatus has it as custom value.

[icinga-migration]

Updated by ricardo on 2015-05-07 22:29:35 +00:00

The configured timezone of the icinga server is always in the "icinga_status" part of every json output.

[icinga-migration]

Updated by mfriedrich on 2015-05-08 08:00:39 +00:00

• Project changed from Core, Classic UI, IDOUtils to Icinga 2
• Subject changed from in_notification_period in status.cgi [Feature GHA: drop CentOS 8 #9231] to in_notification_period for notification objects
• Category changed from 22 to API
• Status changed from Feedback to New

After thinking about that - it does not make sense to add that to 1.x nor 2.x, as with Icinga 2 there are new notification objects which qualify the notification period, but not the host or service itself. We should consider that while implementing the Icinga 2 API.

[icinga-migration]

Updated by mfriedrich on 2015-05-08 08:06:55 +00:00

• Duplicated set to 9231

[icinga-migration]

Updated by ddegois on 2015-05-08 18:11:14 +00:00

ricardo wrote:

The configured timezone of the icinga server is always in the "icinga_status" part of every json output.

I know but it's way too much work.

dnsmichi wrote:

After thinking about that - it does not make sense to add that to 1.x nor 2.x, as with Icinga 2 there are new notification objects which qualify the notification period, but not the host or service itself. We should consider that while implementing the Icinga 2 API.

I'm still looking for a documentation or something to take a look on that and maybe help.
Command submission is a pretty important too and I don't see anything about that :/

[icinga-migration]

Updated by mfriedrich on 2015-06-23 13:30:50 +00:00

• Target Version set to Backlog

[icinga-migration]

Updated by mfriedrich on 2015-09-03 16:47:57 +00:00

• Target Version deleted Backlog

This could be considered some virtual object column which we should discuss whether this makes sense or not.

[icinga-migration]

Updated by mfriedrich on 2015-11-10 09:03:17 +00:00

• Status changed from New to Closed

/v1/objects/notifications?joins=period.is_inside