linux-system-roles
Dependencies
I believe having a * for dependencies is causing Ansible Automation Hub to pull in every version of community.general. This is over 100 versions and it's triggering this bug on Ansible Automation Platform 2.3 (Ansible Core <2.14): https://github.com/ansible/ansible/issues/77911
Please consider setting a min required version instead of the wildcard if possible?
Edit: This may need to be applied elsewhere, not sure if this is the correct place for this issue... I just followed the link from Galaxy.
...
Dependencies This collections requires the following collections for use
ansible.posix: * community.general: * containers.podman: *
by "Ansible Automation Hub" do you mean https://console.redhat.com/ansible/automation-hub ? If so, then the collection there should have no dependencies.
if by "Ansible Automation Hub" you mean https://galaxy.ansible.com/ui/repo/published/fedora/linux_system_roles/ then yes, this might be a problem
What version of ansible-galaxy are you using?
Also, please attach the output of ansible-galaxy collection install -vv fedora.linux_system_roles - I just tried this on a blank centos-9 system and this is what I see:
# ansible-galaxy collection install -vv fedora.linux_system_roles
ansible-galaxy [core 2.14.14]
config file = /etc/ansible/ansible.cfg
configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.9/site-packages/ansible
ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections
executable location = /usr/bin/ansible-galaxy
python version = 3.9.18 (main, Jan 24 2024, 00:00:00) [GCC 11.4.1 20231218 (Red Hat 11.4.1-3)] (/usr/bin/python3)
jinja version = 3.1.2
libyaml = True
Using /etc/ansible/ansible.cfg as config file
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/artifacts/fedora-linux_system_roles-1.76.2.tar.gz to /root/.ansible/tmp/ansible-local-1252zaliqox/tmpye1si89q/fedora-linux_system_roles-1.76.2-gm5buoam
Installing 'fedora.linux_system_roles:1.76.2' to '/root/.ansible/collections/ansible_collections/fedora/linux_system_roles'
Downloading https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/artifacts/ansible-posix-1.5.4.tar.gz to /root/.ansible/tmp/ansible-local-1252zaliqox/tmpye1si89q/ansible-posix-1.5.4-ja7qj1f1
fedora.linux_system_roles:1.76.2 was installed successfully
Installing 'ansible.posix:1.5.4' to '/root/.ansible/collections/ansible_collections/ansible/posix'
Downloading https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/artifacts/containers-podman-1.12.1.tar.gz to /root/.ansible/tmp/ansible-local-1252zaliqox/tmpye1si89q/containers-podman-1.12.1-4m4bzyy2
ansible.posix:1.5.4 was installed successfully
Installing 'containers.podman:1.12.1' to '/root/.ansible/collections/ansible_collections/containers/podman'
containers.podman:1.12.1 was installed successfully
Downloading https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/artifacts/community-general-8.5.0.tar.gz to /root/.ansible/tmp/ansible-local-1252zaliqox/tmpye1si89q/community-general-8.5.0-pg71wjra
Installing 'community.general:8.5.0' to '/root/.ansible/collections/ansible_collections/community/general'
community.general:8.5.0 was installed successfully
took about 30 seconds
by "Ansible Automation Hub" do you mean https://console.redhat.com/ansible/automation-hub ? If so, then the collection there should have no dependencies.
if by "Ansible Automation Hub" you mean https://galaxy.ansible.com/ui/repo/published/fedora/linux_system_roles/ then yes, this might be a problem
What version of ansible-galaxy are you using?
We're using a on premise version of Red Hat's Automation Hub. The actual product maybe called "Private Automation Hub"... The error comes from the Galaxy API on this product.
The read operation timed out
ERROR! Failed to resolve the requested dependencies map. Could not satisfy the following requirements:
* community.general:* (direct request)
I don't think this is something that you can fix but the main reason I opened the issue was to let you know that the wildcard dependency on fedora.linux_system_roles is pulling in EVERY version of the collections listed (on Private Automation Hub). I don't think this is the correct behavior personally. Would it better to specify a >=$MIN_VERSION if possible?
the wildcard dependency on fedora.linux_system_roles is pulling in EVERY version of the collections listed
Can you show me the output of ansible-galaxy collection install fedora.linux_system_roles that shows it downloading every version of community.general, etc.? Or do you just see in /usr/share/ansible/collections/ansible_collections that there are a bunch of versions of community.general?
For the upstream fedora.linux_system_roles, what I really want is a way to say community.general: latest
I don't think this is something that you can fix
If you mean, fix it in PAH, or at least make it work the same way that Galaxy works, then yes, I suppose you could file a bug against PAH.
I'm not opposed to changing fedora.linux_system_roles requirements versions to fix this, but I just don't like making changes like this to workaround a bug in someone else's product, especially since it works elsewhere. I would like to find the root cause of this issue, whether it is a bug in PAH or in ansible-galaxy
Also, if you are an AAP customer, you have access to the fully supported redhat.rhel_system_roles collection, which should not have this issue.
Can you show me the output of ansible-galaxy collection install fedora.linux_system_roles that shows it downloading every version of community.general, etc.?
This is a bit tricky as it's obscured from the end user of Private Automation Hub. We're basically uploading a requirements.yml file to the Private Automation Hub that looks like this:
collections:
...
- name: infra.leapp
version: 1.1.4
- name: community.general
version: 8.2.0
...
After that we click the "Sync" button for remote repos and it pulls down everything we need from public Galaxy. Then in the web UI we browse to the community namespace in PAH we see every version of general downloaded.
Also, if you are an AAP customer, you have access to the fully supported redhat.rhel_system_roles collection, which should not have this issue.
The infra.leapp collection that we're using for in-place upgrades of RHEL is pulling in the fedora.linux_system_roles as a dependency which in turn pulls in 150 versions of community.general. Otherwise we'd for sure useredhat.rhel_system_roles.
For the upstream fedora.linux_system_roles, what I really want is a way to say community.general: latest
Can you omit the version entirely? Or remove the :* part? Curious to see if/how the behavior changes.
I'm not opposed to changing fedora.linux_system_roles requirements versions to fix this, but I just don't like making changes like this to workaround a bug in someone else's product, especially since it works elsewhere. I would like to find the root cause of this issue, whether it is a bug in PAH or in ansible-galaxy
A while back we opened a ticket for this directly with RH. We were using fedora.linux_system_roles in a few of our AAP Job Templates and AAP was bombing trying to sync the project. The RH engineer deployed three different PAH instances, 2.2, 2.3, and 2.4 and was able to recreate the issue in each version. He narrowed it down to this collection and we ultimately resolved case by switching over to the redhat.rhel_system_roles collection (at the time of coding, the RH collection didn't have as many roles as this one... :)). FYI: I also re-opened the case with RH and seeing if they can elaborate a bit more on how PAH is handling the *. My guess is it's "everything" as opposed to what you want, "latest".
We do have a workaround in place so this it's not a show stopper or anything. Basically just manually uploading collections to PAH that try to pull in this collection as a dependency as opposed to using requirements.yml.