-
Notifications
You must be signed in to change notification settings - Fork 56
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
[BUG] Rule Module not correct? #153
Comments
What version of the Checkmk server are you using? |
2.1.0p11 |
The API output has changed in 2.1.0p10. What exactly does the rule module not do? Is the idem potency not correct? |
As I already wrote that only the keys are compared and not the values. |
I'm busy for a few days but I'll have a look at this in the weekend and resolve it |
@diademiemi @robin-tribe29 I also saw that the reason for API changes was this module. Why |
This is because this is how they are stored and what the API expects as input. There was an inconsistency with the API requiring Python as input and the web UI exporting Python, but the API exporting JSON. |
Maybe I miss something but why it was not changed other way around? The API expects a JSON and a JSON would be |
This is how the API expected it as input. Only the output from exporting it was changed in these changes for parity with the web UI. |
I have just put a rule via API with a JSON with correct |
If you go into the UI and look at the rule you will see that the rule is not actually in effect since it will not correctly parse the value |
All values are set correct in my case. And if that would be the case there is still the option to adjust the API that it is reading JSON correctly. Because |
There was a discussion about this in the PR #79. This was the solution chosen by the API developers. In any case this isn't related to the Ansible Collection. |
Yeah and I bet checkmk isn't caring anyway.. |
Happy new year, everybody! Today, I talked to a REST API developer, and he told me that properly using JSON for the value_raw would need a major change in the complete setup part of the CMK backend. It's not planned to do that in the next few releases. Looks like you have to keep on using some extra manual steps to deal with this parameter. |
As this is an upstream issue, and we put some work into the rule module in version 0.16.0 of the collection, I will close this issue. |
Maybe a quick note as a developer of checkmk. We do care about using JSON in the API. That we do not have pure JSON in the body of API requests is also annoying for the developers of checkmk. There are a few historical reasons why it is not straight forward to make the WorkaroundThe string in Why can we not just use JSON?There are two classes that deal with rules Rulespec is just a thin wrapper around a python object, stored in the variable ValueSpecs are kind of a schema definition for RuleSpecs, kind of because they also do a lot more. The API only uses them for validation. Because we cannot change the type of RuleSpecs without breaking almost all MKPs the API would need to convert JSON-arrays to a python tuple in a parsing step. This could be added. In fact we do have buggy support for parsing JSON. For example here is a bug in the Alternative ValueSpec. Here is an example using Alternative to define different option to configure levels. In that example the length of the tuple decides if you want to apply fixed levels or predictive levels. This is not ideal and also a pain for us developers. Unfortunately a lot of legacy code and MKPs depend on this behavior. In short touching this is difficult because a lot of legacy code depends on the current behavior and making changes to the python API of RuleSpec of ValueSpec is risky because it might break a lot of existing code from customers. We really would like to use JSON ourselves. But it is not straight forward to find a solution that works with the constraints we have due to RuleSpec and ValueSpec. |
Hi, we have tried the rule module created by @diademiemi . First of all thanks for that work! But we have tested and debugged it and we aren't sure if that is working correctly. Maybe we are missing a point.
If you get for example
r["extensions"]["conditions"]
it only got the keys but not the values for comparing.Also if the
value_raw
is sorted it not really sorts the keys, instead it sorts every character. Maybe the last is working anyway kinda but the other are not working.We have debugged it with adjusting the following function (reason for debug was to find out if the API output was changed):
PS: I also wonder why the json output was choosed with
()
.. This is not really the standard way like other tools how jq could read it by default.The text was updated successfully, but these errors were encountered: