[BUG] module "rule": finicky syntax

[joernclausen]

I think the syntax of the rules module could need some enhancements in the future - or maybe it's the API itself. Probably it's passing Python fragments through YAML without loss...

This fragment

      rule:
        server_url: "{{ server_url }}"
        site: "{{ site }}"
        automation_user: "{{ automation_user }}"
        automation_secret: "{{ automation_secret }}"
        ruleset: "agent_config:windows_updates"
        rule:
          location:
            folder: "/compute"
            position: "top"
          value_raw: "True"
          properties: {
            "comment": "Windows Updates",
            "description": "check for Windows Updates",
            "disabled": "false"
          }

does work (i.e. creates a correct rule), but is not idempotent. Repeating the playbook will create another identical rule, and so on. The "bug"? With

"disabled": false

(i.e. without the second pair of quotes), the rule works and is idempotent. Yes, this is shown in the examples, but IMHO it is really hard to find, and the different behaviors are totally unexpected.

I am currently trying to find out how to add a condition based on a host tag:

        rule:
          location:
            folder: "/compute"
            position: "top"
          value_raw: "True"
          conditions: {
            "host_tags": [
              {
                "key": "opsys",
                "operator": "is",
                "value": "winserv2019"
              }
            ],
          }
          properties: {
            "comment": "Windows Updates",
            "description": "check for Windows Updates",
            "disabled": false
          }

This should be exactly what the API documentation describes. But again, the rule works (i.e. creates a correct rule with the requested condition) but is no longer idempotent. Is there even a correct syntax??

[robin-checkmk]

See #186 for an in depth discussion about this.
The status is not great, but there is really nothing we can do about it right now.
If your issue is different, from what is written there, do let me know.
Otherwise, I would close this as a duplicate.

[joernclausen]

My problem falls into the same general area, I guess. I didn't get the majority of what is discussed in #186, but at least there was a solution in the mix: Adding

"host_labels": [],
"service_labels": []

to the condition in my example made the rule idempotent!

Replacing Python fragments in the API with JSON is probably a step in the right direction, but if this will really help pushing another markup language through Ansible's YAML we have to see...

It's okay to close this issue.

[joernclausen]

Ah, just noticed: Changing comment or description in an already present rule does not work. Changing disabled from false to true creates a second rule and leaves the one with disabled: false untouched.

[msekania]

@joernclausen

In essence it's about the time when checkmk ansible starts to get Lookup Plugins, with those one can also extract/gather information

[Max-checkmk]

@msekania
Hey Michael, we just talked about Lookup Plugins this week. About what information did you think of?

[msekania]

@Max-checkmk,

I was thinking about info or facts module that returns (in case of rules)

• all rules set
• list of all rulesets
• all rules set for the given rullset

for hosts:

• all hosts in the given folder

for folder:

• tree of the sub-folders under the given folder

[robin-checkmk]

@lgetwan created some first lookup plugins (#415, #417). Maybe someone can take it from there and add more of those? :) lookup_rule would probably be the most complicated one, while the other examples are already WIP in #417.

[github-actions]

This issue has been stale for 60 days. It will close in 7 days.

[lgetwan]

There are more lookup plugins on the way: #476

[lgetwan]

As the host/folder/rule lookup modules are in the main branch, I'll close this bug report.