Getting var type error when attempting to set "params" option

[camilleturiel]

Hey there,

I'm facing an issue when I attempt to set the params options as per described in the library as per below

params:
  notes_url: "{{ ansible_host_notes_url }}"
  notes: "{{ ansible_host_notes_url }}"

It throws the following typing error:

FAILED! => {"changed": false, "msg": "argument params is of type <type 'dict'> and we were unable to convert to list: <type 'dict'> cannot be converted to a list"}

If I set it as a dict:

params:
  - action_url: http://example.org/test

It also fails with the following error:

FAILED! => {"changed": false, "msg": "name"} to retry, use: --limit @/home/ansible/ansible01/eiffage/centreon.retry

[camilleturiel]

By looking in to "library/centreon_host.py":

            if params:
                for k in params:
                    centreon.host.setparameters(name, k['name'], k['value'])
                    has_changed = True

            if applycfg and has_changed:
                centreon.poller.applycfg(instance)
            module.exit_json(changed=has_changed, msg=data)
        except Exception as e:
            module.fail_json(msg='%s' % e.message)

I've been trying to set the value directly using

centreon.host.setparameters(name, "{{ notes_url }}", {{ ansible_host_notes_url }})
Which actually worked...also by looking at this code section I understand that the idempotence is not supported yet on "params" options.

[guillaumewatteeux]

Exactly :(

on CLAPI, getparam works only on CLI. On HTTP request, return empty...

[camilleturiel]

Hmmm....I see ;-) anyway, there's definetely no way to implement idempotency without reading the current value, is getparam...

According to that centreon/centreon#6178 , an issue has already been raised in this regard.

I've got no idea about when this one will get fixed, but as a sake of circumvent I'd see three options so far:

1-Implement a set of options to set those extra attributes inconditionally (breaking idempotency though...).

2-Implement "getparam()" function using a direct call to the CLI at Python module level while waiting for the REST API to get fixed. I agree that this option sounds a bit weird/overkill, but it's clearly the less disruptive one since "centreon-sdk-python" Python module will abstract the underlying request method, so whenever it Centreon REST API will get properly fixed you can fallback to the REST call transparently so no need to modify the "ansible-centreon" neither our playbooks :-).

3-Patch the "centreon-sdk-python" Python module in order to deal with it, since according to issue bellow:

centreon/centreon#6178 (comment)

> {'values': 'myhostname;snmp_community|snmp_version|snmp_community', 'action': 'getparam', 'object': 'HOST'}
> {'result': ['snmp_version : 3', 'snmp_community : ']}

seems that the issue relies on a wrong index typically, so we could also consider implementing a first 'dummy' parameter and then offset the result accordingly. What do you think about it ?

[camilleturiel]

Another quick and dirty but less intrusive circumvent would consits of setting local facts and use it as kind of "Ansible cookie" that can be check to preserve indempotence on those attributes.