ansible.builtin.dnf used, while ansible.builtin.yum has more possibilities and compatibility

[Mik3yZ]

Provide your feedback In the checkmk.general.agent role the module "ansible.builtin.dnf" is being used. However, this is causing issues on older systems, while the module "ansible.builtin.yum" would prevent this.

https://github.com/Checkmk/ansible-collection-checkmk.general/blob/1c9f628169ced1da38a537d3e38adbebb515a23c/roles/agent/tasks/RedHat.yml#L4 https://github.com/Checkmk/ansible-collection-checkmk.general/blob/1c9f628169ced1da38a537d3e38adbebb515a23c/roles/agent/tasks/RedHat.yml#L16

Component Name Component Name: checkmk.general.agent

Ansible Version

$ ansible --version
ansible [core 2.15.12]
  config file = /home/user/repos/ansible-checkmk/linux_agent/ansible.cfg
  configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/user/venvs/ansible-checkmk/lib64/python3.9/site-packages/ansible
  ansible collection location = /home/user/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/user/venvs/ansible-checkmk/bin/ansible
  python version = 3.9.18 (main, Jan  4 2024, 00:00:00) [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] (/home/user/venvs/ansible-checkmk/bin/python3)
  jinja version = 3.1.2
  libyaml = True

Collection Version

$ ansible-galaxy collection list | grep checkmk
checkmk.general                          5.1.0  

Environment RedHat Linux version <=7

[robin-checkmk]

Hey @Mik3yZ and thanks for the report.

The switch to the dnf module happened four months ago and this is the first report of issues. Which kind of issues are you experiencing?

As yum is slowly sunsetting and RHEL 7 (let alone older versions) reached end of maintenance in June of this year (I am aware of ELS), I do believe, that dnf is the sensible way forward. Or to phrase it differently: I do not want to pin users on legacy mechanisms, when it is avoidable.

That being said, if more users speak up here, I will of course consider the vote of the community.

[Mik3yZ]

Hi @robin-checkmk

Using the ansible.builtin.yum module doesn't mean it pins users to yum, as can be seen here: https://docs.ansible.com/ansible/9/collections/ansible/builtin/yum_module.html#parameter-use_backend.

Choices: 
"auto" ← (default)
"yum"
"yum4"
"dnf"
"dnf4"
"dnf5"

The issue i am facing is that the dnf module doesn't support yum, see https://docs.ansible.com/ansible/9/collections/ansible/builtin/dnf_module.html#parameter-use_backend. So, as far as i can see it, the ansible.builtin.yum module has support for both yum and dnf, and is thus the better choice :-)

[robin-checkmk]

From a technical perspective, I see your argument and am almost inclined to follow it.

But: I had a memory in the back of my head, that the yum module was deprecated and just with the release of Ansible Core 2.17 it was removed. So even, if we would bring it back, for users staying up-to-date with their Ansible, the dnf module would be used anyway. And even for the late adopters, the change will come eventually. You can of course change the two locally in your environment, but that will only be a workaround. I hope you will be able to upgrade your infrastructure sooner than later, as that is the real solution here.