New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dev.icinga.com #11434] Config validation for Notification objects should check whether the state filters are valid #4052
Comments
Updated by miken32 on 2016-03-22 18:04:41 +00:00 Actually I came here to report the same problem, but I am getting it at startup after an upgrade to 2.4.4 via RHEL package. I get 247 of these in the startup log, config was working fine in 2.4.3:
No indication where the problem is at all. |
Updated by mfriedrich on 2016-03-22 20:30:05 +00:00
While the error looks similar, I suspect a different issue here. Your stack trace points to notifications so I'd guess you have some Notification apply rules in place which set a faulty filter for "states" and "types". Though there were no changes between 2.4.3 and 2.4.4 in this region. I can reproduce your issue. I guess our configwriter class is not aware of arrays with "special" strings requiring constants, not double quoted string. I need to dig further once there's time. Workaround for now - use the integer representation for these filters. The error happens straight after adding the configitem and then compiling it.
|
Updated by danvaida on 2016-03-23 10:07:40 +00:00 @dnsmichi would you be so kind to provide the integer mappings? It's probably faster for you than for me by looking at the code. So far, I got:
Thanks. |
Updated by gbeutner on 2016-03-23 10:22:15 +00:00 The 'states' array is not an array of strings. Note the difference between:
and the incorrect variant:
OK, Warning, etc. are actually global constants:
|
Updated by gbeutner on 2016-03-23 10:23:34 +00:00
|
Updated by gbeutner on 2016-03-23 10:25:43 +00:00 You can get a list of built-in constants with the console:
|
Updated by danvaida on 2016-03-23 10:50:35 +00:00 @gunnarbeutner thanks! that's a very useful snippet right there. I was able to get a 200 while trying to use the numeric representation (hopefully got the right figures in there).
Anyway, it seems that also the types key is having the same issue, not only the states. |
Updated by mfriedrich on 2016-03-23 11:05:54 +00:00 This affects all arrays which are using constants inside the configuration objects.
We've been discussing whether to allow strings ("OK") inside FilterArrayToInt(). This would allow us to pass such constants as JSON strings, or inside the configuration. |
Updated by gbeutner on 2016-03-23 12:41:24 +00:00
|
Updated by gbeutner on 2016-03-24 08:16:38 +00:00
This is now fixed in the master branch:
This patch needs significant testing before it can be merged into the support branch. |
Updated by Anonymous on 2016-03-24 08:16:43 +00:00
Applied in changeset 5de9a98. |
Updated by mfriedrich on 2016-03-24 09:58:32 +00:00
|
Updated by mfriedrich on 2016-03-24 10:04:48 +00:00
|
Updated by gbeutner on 2016-04-20 08:16:00 +00:00
|
This issue has been migrated from Redmine: https://dev.icinga.com/issues/11434
Created by danvaida on 2016-03-22 14:18:58 +00:00
Assignee: gbeutner
Status: Resolved (closed on 2016-03-24 08:16:43 +00:00)
Target Version: 2.4.5
Last Update: 2016-06-23 13:19:07 +00:00 (in Redmine)
Here's an example:
As you can see lines 5 and 6 as referred to, in the official PagerDuty Icinga2 integration guide, even though the very names of states and types suggest they should be of type array, they seem to be of type string.
A GET request shows:
Comparable with keys such as groups or templates.
Changesets
2016-03-24 08:15:39 +00:00 by (unknown) 5de9a98
2016-04-20 08:07:23 +00:00 by (unknown) 13c4bb0
Relations:
The text was updated successfully, but these errors were encountered: