Role claims Debian 11/12 support, but requires newer Ansible version

[tobiashuste]

Like with #265 before you bump the minimal ansible requirement. While I perfectly understand you don't want to support an EOL ansible, this creates the strange situation that your role "unattended_upgrades" claims to support Debian 11 (bullseye) and Debian 12 (bookworm), but you can not even run the role on Debian 12 (current stable) anymore?! What would you advise to Debian stable users like me then?

Question taken from #337 (comment).

/cc @LeSpocky

[tobiashuste]

The roles continue to support Debian 11 and 12 without issues. In our setup, we manage dependencies as follows:

• We utilize a Python virtual environment on the control host, created using pipenv or uv. This allows us to access specific Ansible versions, rather than relying on potentially outdated versions from the package manager. Alternatively, you can also use pipx, as described in the Ansible documentation: https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#installing-and-upgrading-ansible-with-pipx
• Additionally, we do not run the playbook directly on the control host. Instead, the managed node only requires a properly installed Python environment and must be accessible via SSH from the control host.

We hope this helps clarify our setup and provides a solution for your use case.

The test cases also show the same setup and run the test setup against Debian 11/12, see

ansible-collection-toolkit/.github/workflows/unattended_upgrades.yml

Lines 43 to 47 in 60d2be1

	- "ghcr.io/hifis-net/ubuntu-systemd:24.04"
	- "ghcr.io/hifis-net/ubuntu-systemd:22.04"
	- "ghcr.io/hifis-net/ubuntu-systemd:20.04"
	- "ghcr.io/hifis-net/debian-systemd:12"
	- "ghcr.io/hifis-net/debian-systemd:11"

or https://github.com/hifis-net/ansible-collection-toolkit/actions/runs/13824389298/job/38676574841.

[LeSpocky]

• We utilize a Python virtual environment on the control host, created using pipenv or uv. This allows us to access specific Ansible versions, rather than relying on potentially outdated versions from the package manager. Alternatively, you can also use pipx, as described in the Ansible documentation: https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#installing-and-upgrading-ansible-with-pipx

So you're basically saying one should not use Ansible coming with Debian stable, but run a more recent version in some virtual environment?

• Additionally, we do not run the playbook directly on the control host. Instead, the managed node only requires a properly installed Python environment and must be accessible via SSH from the control host.

I'm aware the control host just sends Python snippets over SSH to the managed host, and they are executed over there. This is standard Ansible behaviour, right?

FWIW: Running the role on Debian 12 with Ansible 2.14 only gives a warning, but seems to do fine otherwise.

[tobiashuste]

As described above, that's how we've set things up. How you implement it is of course up to you. Since this as an open-source solution with the best possible support from our side, we can only take care of officially supported Ansible versions.

However, the roles may still function with older versions, though we will not guarantee it.

[penguineer]

I tend to use Debian Stable as the base for software requirements (independent of the upstream versioning), because it is an environment that has been thoroughly tested for production. Installing a different software in a virtual environment breaks this advantage.

Since the role works with that Ansible version, I propose downgrading the requirement accordingly.

[penguineer]

As a compromise: How about removing Debian 11 support (since this is oldstable for a while now) and downgrade the Ansible requirement to what Debian 12 provides?

[tobiashuste]

The support claimed in

ansible-collection-toolkit/roles/unattended_upgrades/meta/main.yml

Lines 20 to 23 in 60d2be1

	- name: "Debian"
	versions:
	- "bullseye"
	- "bookworm"

is related to the managed node. Ansible should be present on the control node and is not needed on the managed node. So removing support does not change anything with respect to the Ansible requirement.

In any case, the roles might still work with older versions of Ansible as stated above, but we will not provide official support for those versions.