community.crypto pin in requirements.yml resolves to a version that does not support the shipped ansible-core (2.16.16)
Category: Bug Reports / Bootstrapper
Environment
-
ApisCP 3.x —
resources/playbooks/requirements.yml -
ansible-core 2.16.16 (
ansible-core-2.16.16-2.el10_2.1.noarch) -
Collection installed project-local:
/usr/local/apnscp/resources/playbooks/collections/ansible_collections/community/crypto(3.0.5) -
ansible.cfg:collections_path=collections:/usr/share/ansible/collections
Summary
Every bootstrapper run emits:
[WARNING]: Collection community.crypto does not support Ansible version 2.16.16
requirements.yml pins community.crypto: "<3.1", which resolves to 3.0.x — and 3.0.0 onward declares requires_ansible: '>=2.17.0'. The collection is loaded and used anyway: the bootstrap path calls openssl_privatekey, openssl_csr and openssl_certificate_info from it in roles/common/tasks/create-self-signed-certificate.yml. The platform is therefore running a collection the shipped ansible-core explicitly does not support.
Evidence
Installed under resources/playbooks/collections/ansible_collections/ (from requirements.yml, 2026-04-30), with each collection’s meta/runtime.yml floor:
| collection | installed | requires_ansible |
ok on 2.16.16 |
|---|---|---|---|
| community.crypto | 3.0.5 | >=2.17.0 |
no |
| ansible.utils | 6.0.0 | >=2.16.0 |
yes |
| ansible.netcommon | 7.2.0 | >=2.15.0 |
yes |
| community.general | 10.7.0 | >=2.15.0 |
yes |
| community.mysql | 3.15.0 | >=2.9.10 |
yes |
| community.postgresql | 3.14.3 | >=2.9.10 |
yes |
Upstream community.crypto floors: 2.16.0 / 2.17.0 / 2.19.0 → >=2.9.10; 3.0.0 → >=2.17.0. So <3.1 admits exactly the versions that exclude ansible-core 2.16.
Warning occurrences on a live host: 1× in the queued bootstrapper’s timing log (storage/tmp/bootstrap-job.timing*), 12× in storage/logs/bootstrapper.log. It is emitted once per run (Ansible dedupes the message), which is why it reads as cosmetic.
Root cause
requirements.yml:
- name: "community.crypto"
version: "<3.1"
The upper bound caps below a breaking 3.1, but 3.0 is where the ansible-core floor moved from >=2.9.10 to >=2.17.0. Every other pin in the file resolves to a version that supports ansible-core 2.16, so this bound is simply out of step with the ansible-core version the platform ships.
Impact
-
Unsupported module execution on the bootstrap path. Self-signed certificate generation (
roles/common/tasks/create-self-signed-certificate.yml) runs community.crypto 3.0.x modules under an ansible-core they declare unsupported. Today it still works because Ansible only warns, but any 2.17-only API used by those modules is a latent bootstrap failure, and it will surface at the worst time (provisioning). -
Permanent warning noise. Every bootstrap, both the queued and
upcppaths, prints a warning that is easy to mistake for a real fault. -
Fixing the pin does not fix existing hosts. The collections are installed into the project-local
collections/directory at provisioning time, and nothing in the repository re-installs them on update. An existing installation keeps the incompatible collection until the collections directory is refreshed.
Proposed fix
On hosts running ansible-core 2.16:
- name: "community.crypto"
version: ">=2.19,<3.0"
(2.19.x declares >=2.9.10; <3.0 is the effective floor that keeps ansible-core 2.16 supported.)
Alternatively, move the platform to ansible-core ≥2.17, in which case the existing <3.1 bound is correct — but note the bound and the ansible-core version must be changed together, not independently.
For existing installations, refresh the collection after correcting the pin — remove resources/playbooks/collections/ansible_collections/community/crypto and re-run the collection install, or reinstall the collections directory wholesale.
Related observation
requirements.yml also pins ansible.posix: "<=2.0", but the host resolves ansible.posix 2.2.1 from /usr/share/ansible/collections (distro RPM ansible-collection-ansible-posix-2.2.1), because that collection is not installed project-locally. Likewise community.general exists in both roots (10.7.0 project-local, 10.7.3 system). The project-local path is searched first, so the pins govern only the collections actually installed there — ansible.posix is not one of them, and its pin is therefore not enforced.