New collection community.ciscosmb

[qaxi]

Ansible module for Cisco SMB switches - SG300, SG500, SG350, SG550, CBS350
current pluggins - facts, command

Ansible Galaxy: https://galaxy.ansible.com/community/ciscosmb
GitHub: https://github.com/ansible-collections/community.ciscosmb
Issues Tracker: https://github.com/ansible-collections/community.ciscosmb/issues
GitHub Handles: @qaxi
Is the collection part of Automation Hub: No
We meet Collection Requirements: Yes

[tadeboro]

Thank you for your submission, @qaxi.

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 and patience.

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
• 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
• follows development conventions; as well as these other requirements:
  • modules that only gather information are named <something>_info
  • 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
• 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]

Hi @qaxi! Thank you for your quick response. Things are looking great, I just found one minor copy-paste error in the readme file. Once that is fixed and a new release with the changes from this review is uploaded to Ansible Galaxy, the community.ciscosmb is ready for inclusion as far as I am concerned.

[qaxi]

Hi @tadeboro,
I am sorry, I can not find any error in README.md. Can you give me a hint?

[tadeboro]

https://github.com/ansible-collections/community.ciscosmb/blob/main/README.md#code-of-conduct section contains a sentence that mentions Ansible's CoC instead of contributor covenant.

[qaxi]

Thank you ...
fixed by ansible-collections/community.ciscosmb@ef3bfa5

[tadeboro]

Thank you, @qaxi, for your cooperation. As far as I am concerned, the community.ciscosmb is ready for inclusion. Changes made during the review process should be released before Ansible 5.0.0 is out, but since there is a lot of time remaining until that, you can safely wait for another regular release (no need to create a dedicated patch release just for the sake of inclusion).

[Andersson007]

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
  REQUIRED (DONE): merging Misc doc fixes for collection inclusion community.ciscosmb#41
• follows development conventions; as well as these other requirements:
  • modules that only gather information are named <something>_info
  • 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
• 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)
  REQUIRED: would be nice to see supported Python versions in README.md
• 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
  REQUIRED: merging Fix link to issue tracker in galaxy.yml community.ciscosmb#42
• 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
  RECOMMENDATION: putting links to issues/PRs to fragments so that users will find details easily if needed.

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)
  REQUIRED: Clarifications on New collection community.ciscosmb #26 (reply in thread)

[qaxi]

Fixed: Add Py 3.6 to supported python versions #44

[qaxi]

galaxy.xml fix merged #43
Misc doc fixes for collection inclusion merged #41

[qaxi]

The changes are published in release 1.0.3

[qaxi]

@qaxi i see the command module supports_check_mode=True and it's just not considered anywhere.
Can the module not only query devices but change their state? If yes, this can lead to unexpected consequences for users who expect that nothing will change when they invoke the module with check_mode: yes.

... it definitely does not support_check_mode ... PR #45

will release ASAP

[Andersson007]

@qaxi thanks for the fast response and fixing all the things in the collection!
+1 from me to its inclusion

[felixfontein]

This collection will be included in Ansible 5: ansible-community/ansible-build-data#70