Announcing a Change in Support for cisco.asa: Transitioning to Community Maintenance
The cisco.asa Ansible collection is entering a new phase. As of now, this collection will transition from being officially supported by Red Hat to a community-maintained model.
Why the Change?
After careful consideration, we’ve decided to make this change for two main reasons:
Vendor Technology Lifecycle: Cisco Systems has moved on from its ASA firewall technology in favor of its next-generation Firepower solutions. This shift makes it less of a priority for us to continue supporting ASA.
Low Community and Customer Adoption: Over the past year, we’ve seen minimal activity related to this collection, with no customer support escalations and very few issues opened in the GitHub repository. This lack of engagement means it’s time for the community to step in and take ownership.
What This Means for the Community
The Collection Lives On: Don’t worry, the cisco.asa collection will remain available on GitHub. We’re not deleting it!
Change in Maintenance: Red Hat will no longer provide updates, bug fixes, or support. The future development and health of the collection will depend on the efforts of community maintainers.
Future on Automation Hub: The collection will eventually be removed from Red Hat Automation Hub once the transition to the community is complete. However, it will remain available in Ansible Galaxy.
A Call to Action: Become a Community Maintainer!
If your organization still relies on Cisco ASA and you want to ensure this collection continues to thrive, we strongly encourage you to step up and become a community maintainer.f you’re interested, please reply to this thread or comment on the pinned GitHub issue in the cisco.asa repository so we can start the handover process.
My testing is mostly limited to the asa_command, asa_config, and asa_facts modules based on my current simple use cases. I am also testing net_put from the netcommon collection (for scp uploads like firmware updates).
Do further testing with an independent fork of the cisco.asa collection to see if I am able to make any meaningful contributions under an independent code-base with the goal of compatibility with future ansible-core releases. Things like resolving Deprecation Warnings from ansible-core 2.20.
The current release cisco.asa collection version 6.1.0 appears to be stable with ansible-core 2.20, so there is likely not much work needed other than keeping pace with underlying ansible-core deprecations or future api changes.
I’m trying to learn more about the cisco.asa collection codebase and github setup, it looks like the CI sanity tests are succeeding for all currently supported python and ansible-core versions but failing for sanity-py3.12-devel, sanity-py3.12-milestone, sanity-py3.13-devel, and sanity-py3.13-milestone. I am new to GitHub Actions CI and new to ansible sanity testing. Any clue what these failures mean, or what I could do as a community contributor to help resolve them?
I will try to submit a PR for this CI issue (copy tests/sanity/ignore-2.20.txt over to tests/sanity/ignore-2.21.txt). It will by my first PR attempt for an ansible community contribution, is there any quick-start doc or guide that I should follow for making the PR? I’m guessing I clone a fork of the project repo and then make the applicable change and use that to submit the PR against the original project repo when ready.
If I run ansible-test sanity --docker locally, how can I cause that to run against a specific core version and/or dev/milestone? When I ran that recently it appeared to use different versions of python, but maybe not any specific version of ansible-core? It is not clear to me from Sanity Tests — Ansible Community Documentation. Do I need to install dev/milestone core source-code then source hacking/env-setup, or should the core version selection be handled for me automatically by the --docker option?
is there any quick-start doc or guide that I should follow for making the PR? I’m guessing I clone a fork of the project repo and then make the applicable change and use that to submit the PR against the original project repo when ready.
