The Schema has only “rule_config” as required field and is missing something like “notification_rule_id” to make the endpoint itempotent. Like the Ansible modules which first do a lookup to an already defined variable_id in the YAML file and then create or update the endpoint accordingly.
Other endpoints have such a thing somewhere in the OpenAPI definition (different names and
different locations, but it is there). I’m still missing the red thread in the endpoints. The new ones are great because they accept full JSON as direct input (here: rule_config).
Hi Stefan.
I’m not sure if this is a bug. If you use “Create notification rule” it will be create a new rule. As response you will get the id. If you want to update a rule, you need to call “Update notification rule” with teh given id. I think you need to create your own workflow with the given methods.
My workflow is “Ansible”. I’ve written one module for Checkmk and now writing 4 more modules.
I have a CMDB and a reference site where I took our assets and default rules from. The reference site is for looking up the JSON of the desired rule. Then I convert the JSON to YAML to use it in Ansible inventories.
Now I have e.g. 3 default notification rules
to our ticket system (our_id)
to customer’s ticket system (their_id)
fallback (fallback_id)
which I want to be present on all sites/customers. And I only want to maintain exact these 3 rules. Then I need an identifier to exactly create/update/delete pick those rules and ensure they are as they should.
The internal workflow of all Checkmk Ansible modules is the following:
Lookup if the object with “object_id” exists (GET endpoint/object_id).
a. If not present, create it (POST {‘object_id’: 1, ‘rule_config’: {…]}).
b. If present, update it (PUT {‘object_id’: 1, ‘rule_config’: {…]}).
If state should be absent, delete it.
There is no mechanism to write back dynamically created IDs to the YAML. The ID from the reference site/YAML is not existent on the (new) target site. The rule gets created and gets a new ID. The next run then recreates all rules, because the ID is (and will stay) different. Other endpoints have a writable (and required) id fields and work as expected.
For “normal” API users this does not look like a BUG, but like a WISH or like a FEATURE_REQUEST.
For Ansible Checkmk it is crucial and thus a BUG.