[BUG] module "folder" not idempotent

[alien999999999]

I'm experiencing exact symptoms in version 4.2.0 as in issue #289 , except it also happens if no attributes are present.

a folder is created the first time; and then the next times, it fails with

failed: [checkmk -> host(ssh-hostname)] (item=folder_name) => {"ansible_loop_var": "folder", "changed": false, "folder": "folder_name", "msg": "Error calling API. HTTP code 400. Details: b'{\"title\": \"A problem occured.\", \"status\": 400, \"detail\": \"A folder with name \\'folder_name\\' already exists.\"}', URL: https://some_dns_name//cmk/check_mk/api/1.0/domain-types/folder_config/collections/all, Params: {'name': 'folder_name', 'title': 'Folder Name', 'parent': '/', 'attributes': {}}, "}

[msekania]

@alien999999999 there is a bug fix in coming v 4.4.0.

I cannot "reproduce" the issue on updated version.
On the other hand, I have constructed (guessed) the test case from the the text what you wrote.
Anyway, it would be better if you can provide an explicit example/task which fails.

Otherwise:
I know that it's weird (somehow one should compensate deficiencies of the Check-MK REST API), but for better idempotency I always use update_attributes, also when I create a new folder.

[alien999999999]

thanks! (I hope some of the other idempotency issues can also be solved then)

FWIW I actually did use update_attributes, the error code still said attributes, for some reason...

[alien999999999]

it looks like you're talking about #570 ; should I already test this in the devel branch? too bad I didn't see any idempotency fixes in the rule module #552

[msekania]

Yes, you can already test with current devel branch

[msekania]

too bad I didn't see any idempotency fixes in the rule module #552

rule module is generally complicated.
There are several problems, mainly due to the limitations of the current REST API. These problems are well known and not so easy to solve quickly. To my knowledge, the "core" team is aware of this, and eventually we will get the REST API that handles all these value_raw issues differently.

In the meantime, work is being done to improve the current situation as much as possible, perhaps even at the expense of functionality, but with the goal of making the behavior of the rule module more "predictable".

[alien999999999]

yeah, I just end up with a ton of identical rules, i can't delete them, cause they don't match :-( and the rules are like the most used parts on any checkmk, I'll give it a try using devel branch to see if the folder issue actually goes away, for the hosts i had found of a way to at least keep the idempotency in check, i see that there's also changes for that, so i hope that hosts still work for what i have now :-)

[msekania]

@alien999999999,

I know it's not perfect, but in my case I try to reverse engineer one typical rule that I use per rule-set and adjust the rest accordingly, so that check works.

In essence, read the output for already existing rules, or manually created typical rule and try to adjust the input for the rest accordingly.

Here is one of my old "extract" playbooks, (again not the "right" solution, but for the moment might be helpfull)

---
- name: Extract selected rulesets and rules
  hosts: localhost
  gather_facts: false
  vars:
    reject_rulesets: ["host_groups", "host_contactgroups", "active_checks:http", "active_checks:tcp", "discovery_systemd_units_services_rules"]
    site: "my_site"
    server: "my_server"
    url_prefix: 'https://{{ server }}/{{ site }}/check_mk/api/1.0/domain-types/'

  tasks:
    - name: Extract all rulesets
      ansible.builtin.uri:
        url: '{{ url_prefix }}ruleset/collections/all'
        method: get
        status_code: [200]
        headers:
          Authorization: "Bearer {{ automation_user }} {{ automation_secret }}"
          used: "True"
          Accept: "application/json"
          Content-Type: "application/json"
      changed_when: false
      delegate_to: localhost
      # run_once: true
      register: __result_rulesets

    - name: Print __result_rulesets
      ansible.builtin.debug:
        var: __result_rulesets.json

    - name: "Print __result_rulesets.json.value | selectattr('extensions.number_of_rules')"
      ansible.builtin.debug:
        msg: "{{ __result_rulesets.json.value | selectattr('extensions.number_of_rules') }}"
      when: not ansible_check_mode

    - name: Set fact employed_rule_sets
      ansible.builtin.set_fact:
        employed_rule_sets: "{{ __result_rulesets.json.value | selectattr('extensions.number_of_rules') | map(attribute='id') }}"
      when: not ansible_check_mode

    - name: Print employed_rule_sets
      ansible.builtin.debug:
        var: employed_rule_sets
      when: not ansible_check_mode

    - name: Extract all rules from selected rulesets
      ansible.builtin.uri:
        url: '{{ url_prefix }}rule/collections/all?ruleset_name={{ item }}'
        method: get
        status_code: [200]
        headers:
          Authorization: "Bearer {{ automation_user }} {{ automation_secret }}"
          Accept: "application/json"
          Content-Type: "application/json"
      changed_when: false
      delegate_to: localhost
      # run_once: true
      register: output
      loop: "{{ employed_rule_sets }}"
      when: employed_rule_sets is defined and not item in reject_rulesets and not ansible_check_mode

    - name: Print extracted info
      ansible.builtin.debug:
        var: output.results

    - name: Set fact all_employed_rules
      ansible.builtin.set_fact:
        all_employed_rules: "{{ output.results | selectattr('json', 'defined') | map(attribute='json') | flatten | map(attribute='value') | flatten }}"
      when: not ansible_check_mode

    - name: Print all_employed_rules
      ansible.builtin.debug:
        var: all_employed_rules

    - name: Print extracted rules usefull info
      ansible.builtin.debug:
        msg:
          - "id: {{ item.id }}"
          - "title: {{ item.title }}"
          - "extensions:"
          - "{{ item.extensions }}"
      loop: "{{ all_employed_rules }}"
      when: not ansible_check_mode and all_employed_rules is defined

...

[robin-checkmk]

@msekania already explained most of the background on this one. And he seems to understand the issue, which is not true for me.

@alien999999999 can you please provide a minimum working example, of what you are trying to do? Just by looking at the result of a task (and inventory) that we do not know, it is next to impossible to understand the issue. That is why we use issue templates (which you swiftly ignored). So please provide the information requested in the template, so we can properly understand the issue. Thanks!

[alien999999999]

I tested out the folder idempotency in this devel version, also with some changes and it all seemed to work nicely :-) 👍 . We likely can close this when 4.4.0 is released

[robin-checkmk]

We are currently finalizing the release, but with the Easter holidays, it will take another week or two. But we are getting there.