New collection: dellemc.powermax

[anupamaloke]

Ansible collection for Dell PowerMax .

Ansible Galaxy: https://galaxy.ansible.com/ui/repo/published/dellemc/powermax/
GitHub: https://github.com/dell/ansible-powermax
Issues Tracker: https://github.com/dell/ansible-powermax/issues
GitHub Handles: @anupamaloke
Is the collection part of Automation Hub: Yes -> dellemc.powermax
We meet Collection Requirements: Yes

[Andersson007]

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.

Note for reviewers: If you don't know how to check any of the points below, please ask maintainers of the collection you're reviewing or a Steering Committee member for clarifications in comments of corresponding inclusion discussion.

Public availability and communication:

• published on Ansible Galaxy with version 1.0.0 or later
• 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 git repository
• releases of the collection are tagged in its repository

Standards and documentation:

• adheres to semantic versioning
  MUST FIX the collection does not follow SemVer. I see minor changes released in a patch release like in v2.1.1 and in other places. Please add the semver ^ link to your maintainer guidelines or README and make sure your maintainers know how to handle the versions correctly.
  MUST FIX: I don't see any info about check_mode support in the DOCUMENTAION section, you can use the attributes: field for that.
• follows licensing rules
• follows the Ansible documentation standards and the style guide
  MUST FIX: Use C() for choices. like in - present indicates that the SRDF pairing should exist in system. or allowed values are 'Establish' and 'Suspend' and in other places. Check all the docs they satisfy the other formatting requirements from ^ (e.g. you don't end all sentences with a period in DOCUMENTATION, etc.)
• follows development conventions; as well as these other requirements:
  • modules satisfy the concept of idempotency
  • modules that only gather information are named <something>_info
    MUST FIX i see such modules not containing *_info in their names
  • modules that return ansible_facts are named <something>_facts and do not return non-facts
  • other modules must not allow querying information using specific state option values, or similar mechanisms (like state=get or state=query). These features should be moved to <something>_info or <something>_fact modules.
  • check_mode is supported in all _info and _facts modules
    MUST FIX: if port.py is actually an info module, it must support check_mode
    MUST FIX: looks like changed = self.create_host(host_name, initiators) can return None, so can the module return changed=None?
• supports all Python versions supported by all ansible-core versions its supports. 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)
  MUST FIX: ansible-core supports Python 3.12, please add it to your README and tests. Also consider adding ansible-core 2.17 as it's gonna get released withing a few days
• only uses the allowed plugin types in the plugins/ directory
• has README.md
• FQCNs are used for all plugins and modules including ansible.builtin. for builtin ones from ansible-core in all their appearances in the documentation, examples, and return sections, and in extends_documentation_fragment:s.
• documentation and return sections use version_added: containing the collection version for which an option, module or plugin was added (except cases when they were added in the very first release of the collection)
• public plugins, roles and playbooks do not use files outside of meta/, plugins/, roles/, and playbooks/

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
• collection repository should not contain any large objects (binaries) comparatively to the current Galaxy tarball size limit of 20 MB. For example, package installers for testing purposes shouldn't be added.
• collection repository should not contain any unnecessary files like, for example, temporary files. Temporary files should be added to .gitignore.

Tests:

Note for reviewers: If you don't know how to check the points below, please ask maintainers of the collection you're reviewing how you can do it.

• In most cases, CI is set up via GitHub Actions.
• Check .yml files in the .github/workflows directory. There must be at least the sanity section under jobs containing the ansible-test sanity command running against all supported ansible-core versions that must be also listed there, for example, - stable-2.15, - stable-2.16, - stable-2.17.
• Check workflow runs by clicking the Actions tab in the repository's page - you're interested in Scheduled runs, runs against release commits and runs against pull requests.
• If there are no workflows in the Actions tab, ask the collection maintainers how CI is implemented.

• passed ansible-test sanity
  MUST FIX: they don't pass
• if test/sanity/ignore*.txt exists, it MUST not contain error codes listed in the list of errors that must not be ignored
• has CI tests up and running against each of the "major versions" of ansible-base/ansible-core that the collection supports
  MUST FIX: ansible-core 2.17 will be released within days, please add stable-2.17 to your test matrix
• all CI tests MUST run against every pull request
  MUST FIX: I opened a PR and the tests didn't run
• all CI tests MUST run regularly (nightly, or at least once per week)
  MUST FIX: they don't as mariolenz spotted
• sanity tests MUST run against a commit that releases the collection; if they don't pass, the collection won't be released

[Andersson007]

@anupamaloke hi, thanks for submitting the collection. I finished the first round of review. Please take a look at MUST FIXes

[Andersson007]

also @mariolenz spotted that scheduled CI don't run, i've put a mustfix for that point