Feature: Hold / Pin icinga packages

[thesefer]

To prevent issues with Icinga or the database due to updates to the icinga packages I would like to request a feature to:

• unhold packages pre tasks
• install / update packages (maybe add a variable icinga_package_update: False)
• hold packages post tasks

Especially icingadb and the underlying postgres/mysql/mariadb schema are sensible to updates. A mechanism to check the schema and apply the latest / highest update sql file would be fine, too but would be part of a different feature request.

[mkayontour]

Hi, as you mentioned Icinga is very sensible to updates. Therefore we didn't planned to manage updates.
As of now, we only use state: present to ensure the packages are installed, therefore the installation process itself won't update or break your installation.

The collection gotten very complex, I for myself would not want to manage updates and version pinning.
I would advise to have this part of your individual playbook as the update process is heavily individualized as well.

The packages are already a variable, which can be set to a specific version depending on the package manager module.

[thesefer]

hi, sounds reasonable. In my opinion it should be part of the collection because the collection is all about installing and configuring icinga. Version pinning might be over the top, I give you that (I did this for an internal apt role and it gets complex). But a simple package hold / pin / lock in combination with latest and an update variable could be an alternative to that.

But I accept your decision if it is final. For now I'll write a local solution in the playbook.

EDIT: Another reason why it might be a good idea to handle it within the collection itself is that one needs to write a task / role just for this using variables from this collection to hand them over to another set of variables in another task / role instead of doing it here where everything is already accessible, and write it in such a way that the initial install (best case) is still handled by the collection. I think it's easier to just integrate it here.

EDIT2: Regarding the first edit. I forgot the role and it's vars aren't even loaded so there is nothing to handover. One would need to find the packages and hardcode them again into a new variable. This could break down the road if package names change (though highly unlikely). This further hardens my point that it might be better to handle that in the collection and the affected role which installs the package(s).

---

Whatever happens, I still want to provide an example solution with exception of zypper / SELinux because I do not know how it's handled there. From what I have found SELinux doesn't directly manage package locking.

i.e.

yum

community.general.yum_versionlock:
  state: absent
  name: icinga2

ansible.builtin.package_facts:
      manager: "auto"

ansible.builtin.yum:
  name: "icinga2"
  state: latest
when: icinga_package_update or 'icinga2' not in ansible_facts.packages

community.general.yum_versionlock:
  state: present
  name: icinga2

apt

ansible.builtin.package_facts:
      manager: "auto"

#ALTERNATIVE
ansible.builtin.apt:
  pkg: "icinga2"
  state: latest
  allow_change_held_packages: true
when: icinga_package_update or 'icinga2' not in ansible_facts.packages

ansible.builtin.dpkg_selections:
  name: icinga2
  selection: hold

zypper

Problem