I’m writing this because of cisco.catalystcenter (successor to the deprecated cisco.dnac) · ansible-collections/ansible-inclusion · Discussion #88 · GitHub, which asks for including cisco.catalystcenter into the Ansible community package. The collection has a plugins/ directory size of 26 MB (community.general’s plugins/ is 11 MB for comparison), which includes 1052 action plugins and 1127 modules. It also includes a cvp/ folder (which would be included in the Ansible community package as well) that’s 103 MB in size, a roles/ folder of 93 MB, and 17 MB of tests/ (for comparison, community.general has 20 MB of tests/).
Including this collection would increase the size of the package considerably. The size of plugins/ and tests/ is similar to that of the cisco.dnac collection that we removed for Ansible 14.0.0, but that collection did not have such massive roles/ and cvp/ folders.
Also this collection is pretty specific: if you don’t administer Cisco CATALYST Center environments, it is basically dead weight to you.
I’m wondering whether we should be have more specific rules about general usefulness vs. size of collections for inclusion. I think it would be a bad idea to include such a huge collection which is only useful for a very specific group of users. Especially @SteeringCommittee, what do you think?
The primary purpose of the ansible package, was to allow easy upgrade from Ansible 2.9. Over time we’ve added and removed collection based on the inclusion criteria.
I don’t see any value in including such as large or specialised collection in the ansible package.
BTW if we think that “being too large” is a valid reason to not include a collection, it should also be a reason to remove a collection if it grows too large. Otherwise, it would be somewhat unfair to (large) collections that want to be included.
I would recommend that ‘size’ does not become a metric, but general applicability, not all collections need to be in the package.
The original intent of creating collections in the first place was allowing users to adapt the installation to their needs.
The ‘kitchen sync’ approach of the ansible package might be convenient but it can quickly get out of hand, I would recommend focusing more on ‘popularity’ or how likely is the 80% of users to need a certain collection. I know that this is much harder a metric to prove/disprove than size > 10Mb but I do believe it is a much more useful one.
I would also factor in the nature of the collection, network appliances, specially Cisco are normally associated with a more ‘enterprise’ environment, so I would also assign a higher expectation of being able to install their own collection than the average mysql/mariadb/percona user.
I agree that size isn’t a good metric, that’s why I suggested looking at general usefulness vs. size. So a larger size is OK for something that is used by many users: for example community.general is a large collection, but it is also used by many users. If a small but specialized collection is included, it (almost) doesn’t hurt all the users who don’t need it.
Right now our rules are “once it satisfies the inclusion conditions, we include it”. I (still) don’t think this is a good idea, but I also don’t think it’s possible to write down a set of specific rules that result in a good selection of collections to include. I guess we - as the steering committee, or a group of delegates of the SC, or whoever gets designated for that - have to make explicit subjective choices on collections to include (and exclude). Something we tried to avoid so far.
“The Steering Committee can reject a collection inclusion request or exclude a collection from the Ansible package even when the collection satisfies the requirements if the Steering Committee agrees that presence of the collection will significantly deteriorate the Ansible package user experience or the package build process. In case of rejection/removal, the collection maintainers receive comprehensive feedback from the Committee explaining the reasons of starting the process. In case the reasons are fixable, the feedback will contain information what the maintainers need to change.”
Wow, why is this collection so large? Are there large amounts of generated code or binary files or something? I agree that this does not seem like something worth including in the community package.
Hi, I maintain cisco.catalystcenter. Some context: this isn’t really a brand-new specialised collection asking to enter the package, but the successor to cisco.dnac, which shipped in Ansible 5 through 13 and was removed after deprecation during the DNA Center → Catalyst Center rename.
The collection is large — around 1550 modules and 1475 action plugins — but most of it is generated from the Catalyst Center API specification, and only a relatively small subset of modules contains the higher-level Python logic. There are no binary dependencies driving that size, and large repository assets such as screenshots and PDFs are excluded from the published collection through build_ignore.
We’ve also addressed the sanity scalability issue for now by lazily loading the action plugin dependencies. This is currently a workaround while we prepare an ansible-core issue with the measurements and details of the underlying scalability problem; with this change, sanity now passes across the supported ansible-core versions.
I agree that size alone shouldn’t determine inclusion. My ask is simply that cisco.catalystcenter be evaluated as continuity of Cisco automation coverage that the Ansible package carried for nine releases, rather than as an entirely new specialised collection.