Possibly unmaintained collection: cisco.ise

Project Discussions
, ,
1

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:

  1. The issue created by @gotmax23 has comments from previous maintainers that they informed Cisco, but so far nothing happened: Collection not compatible with ansible.utils 6.x.y · Issue #156 · CiscoISE/ansible-ise · GitHub
  2. Unsurprisingly (in the above context) the issue to check for ansible-core 2.19 compatibility has been ignored so far: Validate compatibility with ansible-core 2.19 · Issue #159 · CiscoISE/ansible-ise · GitHub
  3. Apparently the Automation Hub version of the collection hasn’t been updated for a longer time, while releases to Galaxy happened. Questions about that have also been unanswered: Update this collection in Ansible Automation Hub to reflect the version that is in Ansible Galaxy · Issue #158 · CiscoISE/ansible-ise · GitHub

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.

We do have some provision for that in the collection requirements:

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.)

@SteeringCommittee what do you think?

1 Like
2

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…

3

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.

4

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.

While this may not be inline with the collection dependencies policy, this collection could be removed under Identifying and removing an unmaintained collection that has not been deprecated by its maintainers.

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.

5

I would give the vote some more time. Maybe a week, like we usually do. Or at least until Thursday so we can mention it in the community meeting.

That is if there aren’t any good reasons to rush this.

6

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.

7

That would require us to wait another month, starting with an announcement in the Bullhorn.

8

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 :person_shrugging: