New Collection review: netapp.azure

[carchi8py]

We've created a few new collections for our other products (same team that currently support the existing NetApp collections). We do monthly update to each collection (And bug fixes through out the month if needed)

• Ansible Galaxy: https://galaxy.ansible.com/netapp/azure
• Github: https://github.com/ansible-collections/netapp
• Issues Tracker: https://github.com/ansible-collections/netapp/issues
• Github Handles: @carchi8py @lonico

[felixfontein]

Most things have already been covered in the other two collections. I'll add here some points that are specific to this one:

1. https://github.com/ansible-collections/netapp/blob/master/ansible_collections/netapp/azure/galaxy.yml#L10 must have minimum requirement >=1.0.0.
2. https://github.com/ansible-collections/netapp/blob/master/ansible_collections/netapp/azure/plugins/doc_fragments/netapp.py#L14 is invalid.
3. There is a collection build artefact (https://github.com/ansible-collections/netapp/blob/master/ansible_collections/netapp/azure/netapp-azure-20.8.0.tar.gz) inside the repository.

[dmsimard]

Ansible Collections Checklist (short version)

For details about the following points, refer to the Collection Requirements.

Every comment should say whether the reviewer expects it to be addressed, or whether it's optional.

Public availability and communication:

• published on Ansible Galaxy Ansible Galaxy with version 1.0.0 or later
• has a policy of releasing, versioning and deprecation announced to contributors and users in some way
  Was recently added via Releasing, Versioning and Deprecation netapp#93
• have a Code of Conduct (CoC) compatible with the Ansible Code of Conduct (CoC)
  None found, this is required and has been pointed out in other netapp reviews such as this one: New Collection review: netapp.cloudmanager #16 (comment)
• have a publicly available issue tracker that does not require a paid level of service to create an account or view issues
• have a public SCM repository, releases of the collection are tagged in this repository
  This is complicated because multiple collections share the same repository and tags seem to apply to every collection.

Standards and documentation:

• adheres to semantic versioning
  Semantic versioning is important for inclusion in the package so that we may properly pin versions and control major/breaking changes as well as forward/backwards compatibility between versions of Ansible. This has already been pointed out in another review: New Collection review: netapp.cloudmanager #16 (reply in thread)
• follows licensing rules
  Plugins are GPLv3 but galaxy.yml mentions GPLv2. Already pointed out in another review: New collection Review: netapp.um_info #18 (comment)
• follows the Ansible documentation standards and the style guide
• follows development conventions
• only uses allowed plugin types in the plugins/ directory
• has README.md
• documentation, examples, and return use FQCNs for M(..), examples, and seealso subsections
• modules (or plugins) from ansible-base use ansible.builtin. as a FQCN prefix
• documentation and return sections use version_added: containing the collection version for which an option, module or plugin was added
• FQCNs is used for extends_documentation_fragment:, unless you are referring to doc_fragments from ansible-base

Collection management:

• galaxy.yml having tags field set
• collection dependencies must have a lower bound on the version which is at least 1.0.0, and are all part of the ansible package
  Requirement on azure.azcollection in galaxy.yml is set to *, it should be >=1.0.0.
• meta/runtime.yml defines the minimal version of Ansible which the collection works with
  This is missing.
• has changelog, preferably with changelogs/changelog.yaml

Tests:

• passed ansible-test sanity
  Although a subset is likely not run from looking at the results of a PR: use class variable _new_style within class scope instead of attemptin… netapp#87
• if test/sanity/ignore*.txt exists, it does not contain error codes listed here
• has CI tests up and running against each of the "major versions" of ansible-base/ansible-core that the collection supports
• all CI tests run against every pull request
• all CI tests run against a commit that releases the collection; if they don't pass, the collection won't be released
• all CI tests run regularly (nightly, or at least once per week)

[tadeboro]

Just a reminder: collections that want to be part of the Ansible 4.0.0 package need to get approval by 2021-04-26 (full schedule). This inclusion request still has some open issues that need to get addressed by then.

[tadeboro]

Last reminder for inclusion submission

Collections that want to be part of the Ansible 4.0.0 package need to get approval by 2021-04-26, which is just one week away (full schedule). Make sure you submit your collection for the final review a few days before the deadline (reviews take a non-trivial amount of time) and that your collection does meet all criteria listed in the requirements document.

[tadeboro]

Thank you for your submission, @carchi8py.

The items in the checklist can be in one of the following states:

• Items with a checkmark and no attached comment are OK and need no intervention from your side.
• Items with a checkmark that contain a comment will not block the inclusion process, but by following the advice given in the comment, the collection's quality can be improved.
• Items with no checkmark and no extra details are waiting for evaluation.
• Items with no checkmark that contain a comment need your attention.

Feel free to ask any questions and provide feedback. Thanks in advance for your understanding.

For details about the following points, refer to the Collection Requirements.

Public availability and communication:

• published on Ansible Galaxy Ansible Galaxy with version 1.0.0 or later
• has a policy of releasing, versioning and deprecation announced to contributors and users in some way
• have a Code of Conduct (CoC) compatible with the Ansible Code of Conduct (CoC)
• have a publicly available issue tracker that does not require a paid level of service to create an account or view issues
• have a public SCM repository, releases of the collection are tagged in this repository

Standards and documentation:

• adheres to semantic versioning
• follows licensing rules
• follows the Ansible documentation standards and the style guide
  Comment: The netapp documentation fragment is invalid: https://github.com/ansible-collections/netapp/blob/5b7c1f20dfc383c85f6d44c578670b7fe27eca05/ansible_collections/netapp/azure/plugins/doc_fragments/netapp.py#L14, but is not used anywhere. This will not block the inclusion, but should be fixed/simplified in the future.
• follows development conventions
• supports Python 2.6 or greater and Python 3.5 or greater. If it does not, read the full guidelines to see if you qualify for an exception and document the unsupported Python versions in the collection README.md and in every module and plugin (or in doc fragments)
• only uses the allowed plugin types in the plugins/ directory
• has README.md
• documentation, examples, and return sections use FQCNs for the M(..) format macros when referring to modules
• modules (or plugins) from ansible-core use ansible.builtin. as a FQCN prefix
• documentation and return sections use version_added: containing the collection version for which an option, module or plugin was added
• FQCNs are used for extends_documentation_fragment:, unless you are referring to doc_fragments from ansible-core

Collection management:

• galaxy.yml having tags field set
• collection dependencies must have a lower bound on the version which is at least 1.0.0, and are all part of the ansible package
• meta/runtime.yml defines the minimal version of Ansible which the collection works with
• has changelog, preferably with changelogs/changelog.yaml

Tests:

• passed ansible-test sanity
• if test/sanity/ignore*.txt exists, it does not contain error codes listed here
• has CI tests up and running against each of the "major versions" of ansible-base/ansible-core that the collection supports
• all CI tests run against every pull request
• all CI tests run against a commit that releases the collection; if they don't pass, the collection won't be released
• all CI tests run regularly (nightly, or at least once per week)

[tadeboro]

@lonico Yes, the CI stuff is fixed since all of the netapp.* collections share the same CI pipeline.

[lonico]

changes pushed to GitHub.

[tadeboro]

Thank you, @carchi8py, for your perseverance. Once the next release hits Ansible Galaxy, this collection is ready for inclusion as far as I am concerned. Congratulations!

[carchi8py]

@tadeboro the changes above have been uploaded in to latest release of azure https://galaxy.ansible.com/netapp/azure

[felixfontein]

I agree with @tadeboro.

[felixfontein]

This collection has been prepared for inclusion in Ansible 4 in this PR: ansible-community/ansible-build-data#66

[tadeboro]

The netapp.azure Ansible Collection was accepted into the Ansible community package. The relevant part of the community meeting starts here.

Congratulations!