discovery and activation - generic error: "Error calling API"

[jaydabi]

When using discovery and/or activation modules, a generic error message is thrown:

{"changed": false, "http_code": -1, "msg": "Error calling API"}

The host module works as expected.

Ansible Version

$ .local/bin/ansible --version
ansible [core 2.12.4]
config file = None
configured module search path = ['/home/jonas/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /home/jonas/.local/lib/python3.8/site-packages/ansible
ansible collection location = /home/jonas/.ansible/collections:/usr/share/ansible/collections
executable location = .local/bin/ansible
python version = 3.8.10 (default, Mar 15 2022, 12:22:08) [GCC 9.4.0]
jinja version = 3.1.1
libyaml = True

Server Version

Checkmk Free Edition 2.1.0b4

Tasks to reproduce

- name: Add host to check_mk inventory. - works as expected
  delegate_to: localhost
  become: no
  tribe29.checkmk.host:
    server_url: '{{ check_mk_url }}'
    site: '{{ check_mk_site }}'
    automation_user: 'automation'
    automation_secret: 'super-secret-pass'
    host_name: '{{ inventory_hostname }}'
    folder: '/'
    state: 'present'

- name: Add newly discovered services. - throws generic error message
  delegate_to: localhost
  become: no
  tribe29.checkmk.discovery:
    server_url: '{{ check_mk_url }}'
    site: '{{ check_mk_site }}'
    automation_user: 'automation'
    automation_secret: 'super-secret-pass'
    host_name: '{{ inventory_hostname }}'
    state: 'new'

- name: Activate changes on all sites. - throws generic error message
  delegate_to: localhost
  become: no
  tribe29.checkmk.activation:
    server_url: '{{ check_mk_url }}'
    site: '{{ check_mk_site }}'
    automation_user: 'automation'
    automation_secret: 'super-secret-pass'

Collection Version

$ ansible-galaxy collection list tribe29.checkmk

# /home/jonas/.ansible/collections/ansible_collections
Collection      Version
--------------- -------
tribe29.checkmk 0.1.0

[robin-checkmk]

@jaydabi One hint up front: Activate changes only needs to run_once. But I cannot reproduce an error during activation in the 0.2.0 release of the collection, if I omit the task in the middle.
I can however reproduce the issue with the discovery, both with new and fix_all. Both for the Checkmk beta and the stable release.

Update: Can you please check, whether the hosts you are trying to discover have a valid DNS name or IP address set? If you get an error message in the GUI stating that the hostname is not resolvable via DNS, you will receive the aforementioned error.

[elwood218]

Hi, we had the same issue. I was deploying it with Ansible. When doing the task like follow with about 6 hosts the first 2 or 3 were successful but the other got this error.

- name: "Add newly discovered services, update labels and remove vanished services on host."
  tribe29.checkmk.discovery:
    server_url: "https://{{ cmk_central }}/"
    site: "{{ cmk_central_site }}"
    automation_user: "{{ cmk_site_user }}"
    automation_secret: "{{ cmk_site_password }}"
    host_name: "{{ cmk_host_name | default(host_name) }}"
    state: "fix_all"
  delegate_to: localhost
  become: no

So what we did, we run that task once but loop over the hosts which worked.

- name: "Add newly discovered services, update labels and remove vanished services on host."
  tribe29.checkmk.discovery:
    server_url: "https://{{ cmk_central }}/"
    site: "{{ cmk_central_site }}"
    automation_user: "{{ cmk_site_user }}"
    automation_secret: "{{ cmk_site_password }}"
    host_name: "{{ hostvars[item]['cmk_host_name'] | default(hostvars[item]['host_name']) }}"
    state: "fix_all"
  delegate_to: localhost
  loop: "{{ play_hosts }}"
#  loop_control:
#   pause: 3
  run_once: true
  become: no

I don't understand why but maybe this helps finding the cause.. The difference by Ansible within those tasks is that the first is run parallel and the "loop" is one after the other.

[robin-checkmk]

Hi @elwood218 and thanks for your feedback!
I am not sure, that this is the same issue. Once #35 is implemented, we should look at the distinct error message.
If I understood you correctly, you have a working state currently, so I would be glad if you can create a dedicated issue, once #35 is implemented. That will help us improve the module, as the behavior you outline definitely is not desirable.

[robin-checkmk]

@jaydabi I did not hear back from you, but we improved the logging with the current release. If there is still a module-related error, feel free to reopen the issue.
@elwood218 If you still encounter your error after updating the collection to the current release, please open a new issue.
Thanks to you two! 🚀