Some days ago netapp.storagegrid 21.15.0 was deleted from Ansible Galaxy (see issue for more info), despite that collection being part of Ansible 12.0.0a4.
This makes it impossible to rebuild Ansible 12.0.0a4 (which isn’t that big a problem, since it’s an alpha release), but also prevents any new Ansible 12 release from being created: when trying to compose the changelog, antsibull-build fails as it cannot find netapp.storagegrid 21.15.0.
To fix the current situation, we basically either have to adjust the dependency data for the Ansible 12.0.0a4 release (PR for that), or somehow teach antsibull-build to build a changelog when a release is missing. (@gotmax23 suggested to update the 12.0.0a4 dependency data and update the guidelines in the release management Matrix room.)
This is one of the reasons why galaxy initially did not allow deletion by users, required admin.
I would add a check to galaxy (admin overridable) that won’t delete a collection/collection version if it leaves unmet dependencies. This is not easy to add as it would require not only being able to run ‘resolving deps’ as ansible-galaxy does, but keeping that info on each namespace/collection version group.
I think that we should add this collection requirement.
However, if someone doesn’t follow this requirement and deletes a release on galaxy we run into the same problem. As a requirement it’s fine, but in the long run it wouldn’t prevent a situation like the one we’re running into at the moment.
We definitely do, but at least then we can force them to re-upload that version since they violated this rule. (If they don’t do that, well, we still have a problem…)
I agree with updating a-b-d and the collection requirements to prevent this from happening again, but as mentioned in https://github.com/ansible-community/ansible-build-data/pull/553 neither I nor the other release-management-wg members are particularly happy about having to retroactively change a release’s build data. I think we should also ask Galaxy team to consider disabling collection deletion on the public Galaxy instance at least for collections in Ansible if not for everything to prevent this from happening again. If collection maintainers have a really compelling reason to remove a collection release, and it hasn’t already been added to an Ansible release, it can be deleted by an admin.
