Skip to content

rabbitmq_user doesn't support Ansible check mode #107

Open
@aderixon

Description

@aderixon
SUMMARY

When applied with ansible --check, the rabbitmq_user module always makes any required changes to the users anyway. This is unexpected behaviour and potentially disruptive to the RabbitMQ service.

ISSUE TYPE
  • Bug Report
COMPONENT NAME

rabbitmq_user

ANSIBLE VERSION
ansible 2.9.23
  config file = /home/test/src/working/ansible/ansible.cfg
  configured module search path = [u'/usr/share/ansible']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.5 (default, Nov 16 2020, 22:23:17) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44)]
COLLECTION VERSION
Collection         Version
------------------ -------
community.rabbitmq 1.1.0  
CONFIGURATION
ANSIBLE_PIPELINING(/home/test/src/working/ansible/ansible.cfg) = True
DEFAULT_MODULE_PATH(/home/test/src/working/ansible/ansible.cfg) = [u'/usr/share/ansible']
HOST_KEY_CHECKING(/home/test/src/working/ansible/ansible.cfg) = False
TRANSFORM_INVALID_GROUP_CHARS(/home/test/src/working/ansible/ansible.cfg) = ignore
OS / ENVIRONMENT

CentOS 7.9

STEPS TO REPRODUCE

Create a new RabbitMQ user using the rabbitmq_user module, but apply the playbook using ansible-playbook --check, which should show what would happen.

- hosts: all
  become: true
  tasks:
  - name: configure rabbitmq users
    community.rabbitmq.rabbitmq_user:
      name: "test-user"
      password: "pebhebEk"
      configure_priv: "^$"
      read_priv: "^$"
      write_priv: "^$"
      state: "present"
$ ansible-playbook -i hosts rabbitmq-test.yml -l mqserver.test.com -K --check -v
$ ansible-playbook -i hosts rabbitmq-test.yml -l mqserver.test.com -K --check -v
EXPECTED RESULTS

Ansible output would consistently show 'changed: [mqserver.test.com] => {"changed": true, ...}' for task but test-user would not actually be created on RabbitMQ host.

ACTUAL RESULTS

test-user is created the first time playbook is applied with --check. A second run outputs 'ok: ... "changed": false', indicating that the user now exists.

ansible(master)] 1023$ ansible-playbook -i hosts rabbitmq-test.yml -l mqserver.test.com -K --check -v
Using /home/test/src/working/ansible/ansible.cfg as config file
BECOME password: 

PLAY [all] *********************************************************************

TASK [Gathering Facts] *********************************************************
ok: [mqserver.test.com]

TASK [configure rabbitmq users] ************************************************
changed: [mqserver.test.com] => {"changed": true, "state": "present", "user": "test-user"}

PLAY RECAP *********************************************************************
mqserver.test.com          : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

ansible(master)] 1024$ ansible-playbook -i hosts rabbitmq-test.yml -l mqserver.test.com -K --check -v
Using /home/test/src/working/ansible/ansible.cfg as config file
BECOME password: 

PLAY [all] *********************************************************************

TASK [Gathering Facts] *********************************************************
ok: [mqserver.test.com]

TASK [configure rabbitmq users] ************************************************
ok: [mqserver.test.com] => {"changed": false, "state": "present", "user": "test-user"}

PLAY RECAP *********************************************************************
mqserver.test.com          : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   


[root@mqserver test]# rabbitmqctl list_users | grep test-user
test-user	[]

This is because the code for rabbitmq_user.py does not include support for running in check mode (e.g. compare implementation of _exec() with rabbitmq_vhost.py, which explicitly tests for check_mode being enabled and does not execute rabbitmqctl if so).
I have a modified rabbitmq_user implementation that includes check_mode support (based on rabbitmq_vhost.py) if you want a PR.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions