In April, when ansible.utils 6.0.0 got released, we hard to restrict ansible.utils to <6.0.0 for Ansible 12 since three Cisco collections dependend on ansible.utils < 6.0.0. @gotmax23 created issues for these, and since then two of the collections have been updated to also support ansible.utils 6.x.y.
Unfortunately cisco.ise was not yet updated, and it is not clear whether it is still maintained:
Especially the ansible.utils incompatibility is quite a problem, since this results in all Ansible 12 pre-releases so far using the previous major release of ansible.utils, and also blocking these pre-releases of using new release of cisco.dnac which requires ansible.utils >= 6.0.0.
If a collection has a too strict dependency for a longer time, and forces another collection depended on to be held back, that collection will be removed from the next major Ansible release. What “longer time” means depends on when the next Ansible major release happens. If a dependent collection prevents a new major version of a collection it depends on to be included in the next major Ansible release, the dependent collection will be removed from that major release to avoid blocking the collection being depended on.
Now feature freeze is still some time out (a bit more than one month, see the Ansible 12 release schedule), but since early testing for Ansible 12 is particuarly important due to the changes to ansible-core 2.19, I would suggest we act now.
I would suggest to start a vote in a few days to remove cisco.ise from Ansible 12, unless it becomes maintained again (and a new working release made) before Ansible 12 feature freeze. Is anyone opposed to this? This would not follow our standard procedures for collection removal (Ansible Community Package Collections Removal Process — Ansible Community Documentation), but I think this is a valid exception due to the special nature. (Also the inclusion rules explicitly mention that the collection can be removed on feature freeze in case it hasn’t updated its dependencies without any vote or any more advance warning.)
If cisco.ise still blocks other collections in Ansible 12, I think we should get rid of it ASAP.
We can re-add it in case they fix their dependencies and show they’re compatible with ansible-core 2.19. Although I’m not too sure if we really want to do this, seeing that the maintainers don’t react on the issues we create…
I could start a vote tomorrow, with end date on Tuesday. That’s quite short, but I hope long enough for most to cast their vote. If nobody objects to this, I’ll do that.
Thanks for starting the discussion! Yeah, I think it’s time to move forward with removal. I would be fine with waiting until feature freeze if there had been any sort of acknowledgement from the maintainers or stated plans to fix the issue, but there hasn’t been. Also, the original issue said
Note that Ansible 12 feature freeze takes place on June 17th, but please endeavor to make this update as soon as you can.
and June 17th is Tuesday. Even though the feature freeze was pushed back, they did not take any action within the original timeline.
Either way, I think this makes sense to remove it now (we can always add it back before feature freeze), so we can stop holding back the versions of the other collections.
I would rush it to be able to do another Ansible 12 pre-release that contains a selection of collections thats closer to the final version, including ansible.utils 6.0.0. After all that collection has been released two months ago, and still hasn’t shown up in any Ansible 12 pre-release.
Well, give it try to open a vote ending Tuesday if you want to… but it’s on very short notice, so I don’t know if we get enough votes / reach quorum up until then
Should cisco.ise be removed from Ansible 12 (unless the collection is updated and sufficiently tested before in time before feature freeze)? (Steering Committee vote)
Remove cisco.ise from Ansible 12
Do not remove cisco.ise from Ansible 12
0voters
Should cisco.ise be removed from Ansible 12 (unless the collection is updated and sufficiently tested before in time before feature freeze)? (Community vote)
The ansible.utils issue seems easier to fix. I created a PR to remove ansible.utils with playbook I threw together and then grepped to find the several imports that needed to be readded/removed. There are a lot of files, so reviewing is going to take longer than fixing it.
ansible.utils 6.0.0 had no breaking changes (changelog) except dropping support for ansible-core < 2.16, so there’s no need to keep ansible.utils restricted to < 6 for cisco.ise.
(Obviously removing the ansible.utils dependency completely is better long-term. I really appreciate your work (and hope it won’t simply be ignored), I just wanted to point out that the amount of work needed by the maintainers to fix the issue is trivial. This not having been done for two months is a bad sign.)
