We officially have NSO as a Cisco Ansible collection, aligning to the new way Ansible handles non-core modules:
https://galaxy.ansible.com/cisco/nso
If you have issues or pull requests you can open them on the following collection repo:
https://github.com/CiscoDevNet/ansible-nso
Why did we do this?
Ansible has changed their software architecture to remove “non-core” modules from their distribution. NSO was previously a part of the Ansible distribution, but as a result of the most recent versions, must be installed manually through the collections / galaxy process. We are aligning to what Ansible has dictated in terms of the software distribution process for third party modules, and we are aligning to how other Cisco software products such as ACI and Meraki have already adopted this model. This was not as a result of some additional feature or functionality, but merely keeping up with Red Hat’s decision to change the way Ansible handles non-Red Hat modules.
What benefit is there to this change?
The value to having NSO in collections allows us to be more nimble in providing updates and keeping track of issues. Since the NSO Ansible code was buried in the monolithic Ansible Git Repository under the old architecture, and there were many, many, issues on Ansible and its suite of modules being opened and closed, it was harder to manage ownership and maintenance. Since our code is decoupled from the Ansible repo, if customers have issues or feature requests, they can submit them on the GitHub link above.
In addition to moving to the collection architecture, we are taking the chance to add in a few more examples into the documentation and have the examples align to the NSO Reservable Sandbox environment to make it easier for new users to get started.
From a pure functionality perspective, there should not be any change (apart from playbooks needing the new collections syntax), and in the long run it should help our team better manage the code base and keep on top of issues and feature requests as they come in.
