yum_versionlock not idempotent when version provided

[tedgin]

Summary

When I specify that yum_versionlock ensures that a package is locked to a specific version, and the package is already locked to that version. yum_versionlock reports a state change, even though yum versionlock list shows no change. This appears to be a regression, because if I revert back to community.general version 3.2, yum_versionlock doesn't report a state change.

Here's an example task.

---
name: lock iCommands to version 4.2.8
community.general.yum_versionlock:
  name: irods-icommands-4.2.8
  state: present

Issue Type

Bug Report

Component Name

yum_versionlock

Ansible Version

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

Community.general Version

$ ansible-galaxy collection list community.general

# /home/tedgin/.local/lib/python3.8/site-packages/ansible_collections
Collection        Version
----------------- -------
community.general 4.7.0  

# /home/tedgin/.ansible/collections/ansible_collections
Collection        Version
----------------- -------
community.general 4.7.0  

Configuration

$ ansible-config dump --only-changed
ANSIBLE_PIPELINING(/home/tedgin/.ansible.cfg) = True
DEFAULT_TIMEOUT(/home/tedgin/.ansible.cfg) = 20
DEFAULT_VAULT_PASSWORD_FILE(env: ANSIBLE_VAULT_PASSWORD_FILE) = /home/tedgin/.ansible_vault_pass.txt
INTERPRETER_PYTHON(/home/tedgin/.ansible.cfg) = /usr/bin/python3
RETRY_FILES_ENABLED(/home/tedgin/.ansible.cfg) = False

OS / Environment

Ansible control node is running either CentOS 7 or Ubuntu 20.04. The managed node is running CentOS 7.

Steps to Reproduce

---
- name: demo issue
  hosts: provider_configured.dstesting
  tasks:
    - name: lock iCommands to version 4.2.8
      community.general.yum_versionlock:
        name: irods-icommands-4.2.8
        state: present

Expected Results

I expect yum_versionlock to respond with ok.

Actual Results

$ # Here's what yum thinks is locked before running the task.
$ ssh provider_configured.dstesting yum versionlock list
Loaded plugins: fastestmirror, ovl, versionlock
0:irods-netcdf-icommands-4.2.8.0-1.*
versionlock list done
$ 
$ ansible-playbook demo.yml

PLAY [demo] ********************************************************************************************************

TASK [Gathering Facts] *********************************************************************************************
ok: [provider_configured.dstesting]

TASK [lock iCommands to version 4.2.8] *****************************************************************************
changed: [provider_configured.dstesting]

PLAY RECAP *********************************************************************************************************
provider_configured.dstesting : ok=1   changed=1    unreachable=0    failed=0    skipped=9    rescued=0    ignored=0 

$ # To ensure nothing change, here's what `yum versionlock` thinks is locked after running the task.
$ ssh provider_configured.dstesting yum versionlock list
Loaded plugins: fastestmirror, ovl, versionlock
0:irods-netcdf-icommands-4.2.8.0-1.*
versionlock list done

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibullbot]

Files identified in the description:

• plugins/modules/packaging/os/yum_versionlock.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

cc @aminvakil @florianpaulhoberg
click here for bot help

[ansibullbot]

Files identified in the description:

• plugins/modules/yum_versionlock.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

cc @gyptazy
click here for bot help

[matt-horwood-mayden]

any news on this?

[felixfontein]

There has been no functional change to this module since April 2022, so I guess this hasn't been fixed. There are no active maintainers for it, so if someone wants to contribute a fix, that's definitely welcome!

[gyptazy]

Hey,

just added PR #6861 which should care about version suffixes, now. Please give it a try and let me know if it works for you. Now, it should be able to handle the plain package name, as well as the package name including its version as a suffix properly.

Cheers,
gyptazy

[felixfontein]

While looking at the PR I noticed that the module never mentions that passing a version is actually allowed input. So from that point of view, this isn't a bug, but a feature request. That this worked in an earlier version of the module was a random coincidence, also in community.general 3.2.0 the documentation and examples didn't mention that providing a version is supported (see https://github.com/ansible-collections/community.general/blob/3.2.0/plugins/modules/packaging/os/yum_versionlock.py for the code from that version, which includes the documentation and the examples).

[gyptazy]

Fair enough, I've just adjusted the PR. This should fit and cover this, now.