Infoblox.nios_modules inclusion

[Vaishnavi-infoblox]

Ansible Galaxy: https://galaxy.ansible.com/infoblox/nios_modules
GitHub repo: https://github.com/infobloxopen/infoblox-ansible
Issue tracker: https://github.com/infobloxopen/infoblox-ansible/issues
Contacts: @Vaishnavi-infoblox or @anagha-infoblox

Referring - https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst

1. Is unit test integration a mandatory ask?
2. Repository Management: It says that we need to set “Allow merge commits: disallowed” for only those repos that are under “ansible-collections”. Our collection is under infobloxopen/infoblox-ansible. So guess we don’t have to do any change to our repo, please confirm on this.
3. meta/runtime.yml – under which directory should meta directory come
4. Modules & Plugins –when is this applicable? (or only applicable while adding new modules and plugins) or should we change something in our existing code?
5. Versioning and deprecation – Is there something pending from Infoblox side which we should address?

[tadeboro]

1. Is unit test integration a mandatory ask?

No. Sanity tests must be executed in CI, integration tests should be there but are not required to be executed as part of the CI/CD process, and unit tests are nice to have, but not mandatory.

2. Repository Management: It says that we need to set “Allow merge commits: disallowed” for only those repos that are under “ansible-collections”. Our collection is under infobloxopen/infoblox-ansible. So guess we don’t have to do any change to our repo, please confirm on this.

You can follow your own preferred development process. But that process must fulfill some requirements (like testing every PR and push so releases are tested).

3. meta/runtime.yml – under which directory should meta directory come

In the root of the repo. See for example https://github.com/ansible-collections/community.sops

4. Modules & Plugins –when is this applicable? (or only applicable while adding new modules and plugins) or should we change something in our existing code?

You will need to update your existing code if it does not follow the rules described there (the reviewer will tell you what needs to be fixed).

5. Versioning and deprecation – Is there something pending from Infoblox side which we should address?

You should have this information available somewhere (for example, in the README file) where users can find it easily. It should briefly explain how version management is done in your collection (when do you break API, how long do you support each stable branch, etc.).

[Vaishnavi-infoblox]

Hi @tadeboro,

Thank you for the clarification.

One more doubt -
"Branch name and configuration
This subsection is only for repositories under ansible-collections! Other collection repositories can also follow these guidelines, but do not have to. "

As of now we don't have infoblox-ansible under ansible-collections, so I guess we don't have to do anything as of now. Please confirm.

[felixfontein]

@Vaishnavi-infoblox that's correct. That section is not required for your collection.

[Vaishnavi-infoblox]

Hi,

We have made our code compliant to Ansible-3.0.0. Below are the links.

Ansible Galaxy: https://galaxy.ansible.com/infoblox/nios_modules
GitHub repo: https://github.com/infobloxopen/infoblox-ansible
Issue tracker: https://github.com/infobloxopen/infoblox-ansible/issues
Contacts: @Vaishnavi-infoblox or [email protected]

[dmsimard]

Separate from the review, additional improvement opportunities provided by ansible_reviewer:

../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_aaaa_record.py
opt name: line 1 does not end with a dot
opt view: line 1 does not end with a dot
opt ttl: line 1 does not end with a dot
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
examples: "- name" of #4 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_a_record.py
opt name: line 1 does not end with a dot
opt view: line 1 does not end with a dot
opt ipv4addr: line 1 does not end with a dot
opt ttl: line 1 does not end with a dot
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
examples: "- name" of #4 does not start with a capital letter
examples: "- name" of #5 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_cname_record.py
opt name: line 1 does not end with a dot
opt view: line 1 does not end with a dot
opt ttl: line 1 does not end with a dot
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_dns_view.py
opt extattrs: explicit "require: false" declaration
opt comment: explicit "require: false" declaration
opt state: explicit "require: false" declaration
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
examples: "- name" of #4 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_fixed_address.py
description: line 2 does not end with a dot
opt network_view: explicit "require: false" declaration
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
examples: "- name" of #4 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_host_record.py
opt view: line 1 does not end with a dot
opt configure_for_dns: explicit "require: false" declaration
opt ipv4addrs: line 1 does not end with a dot
opt ipv6addrs: line 1 does not end with a dot
opt ttl: line 1 does not end with a dot
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
examples: "- name" of #4 does not start with a capital letter
examples: "- name" of #5 does not start with a capital letter
examples: "- name" of #6 does not start with a capital letter
examples: "- name" of #7 does not start with a capital letter
examples: "- name" of #8 does not start with a capital letter
examples: "- name" of #9 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_member.py
opt config_addr_type: line 1 does not end with a dot
opt use_syslog_proxy_setting: line 1 does not end with a dot
opt external_syslog_server_enable: line 1 does not end with a dot
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
examples: "- name" of #4 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_mx_record.py
opt name: line 1 does not end with a dot
opt view: line 1 does not end with a dot
opt ttl: line 1 does not end with a dot
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_naptr_record.py
opt name: line 1 does not end with a dot
opt view: line 1 does not end with a dot
opt services: explicit "require: false" declaration
opt flags: explicit "require: false" declaration
opt regexp: explicit "require: false" declaration
opt ttl: line 1 does not end with a dot
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_network.py
description: line 2 does not end with a dot
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
examples: "- name" of #4 does not start with a capital letter
examples: "- name" of #5 does not start with a capital letter
examples: "- name" of #6 does not start with a capital letter
examples: "- name" of #7 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_network_view.py
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
examples: "- name" of #4 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_nsgroup.py
opt is_grid_default: explicit "require: false" declaration
opt use_external_primary: explicit "require: false" declaration
opt external_primaries: explicit "require: false" declaration
opt extattrs: explicit "require: false" declaration
opt comment: explicit "require: false" declaration
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_ptr_record.py
opt name: explicit "require: false" declaration
opt view: line 1 does not end with a dot
opt view: explicit "require: false" declaration
no "notes" section, it should, at least, contain info about check_mode support
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_srv_record.py
opt name: line 1 does not end with a dot
opt view: line 1 does not end with a dot
opt ttl: line 1 does not end with a dot
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_txt_record.py
opt name: line 1 does not end with a dot
opt view: line 1 does not end with a dot
opt ttl: line 1 does not end with a dot
no "notes" section, it should, at least, contain info about check_mode support
=========
../infoblox/infoblox-ansible/ansible_collections/infoblox/nios_modules/plugins/modules/nios_zone.py
opt restart_if_needed: line 1 does not end with a dot
no "notes" section, it should, at least, contain info about check_mode support
examples: "- name" of #1 does not start with a capital letter
examples: "- name" of #2 does not start with a capital letter
examples: "- name" of #3 does not start with a capital letter
examples: "- name" of #4 does not start with a capital letter
examples: "- name" of #5 does not start with a capital letter
examples: "- name" of #6 does not start with a capital letter
examples: "- name" of #7 does not start with a capital letter

[felixfontein]

Please note that there have been quite a few fixes (mostly sanity, but also other things) for the nios modules in community.general:

• Fix the docs for dig and nios. community.general#388
• Fix various sanity errors in plugins community.general#881
• Remove redundant aliases from NIOS modules community.general#1223
• Tidy up validate-modules nonexistent-parameter-documented community.general#1389
• Tidy up validate-modules:doc-elements-mismatch community.general#1399
• Tidy up validate-modules:doc-required-mismatch community.general#1415
• fix so module nios_host_record can remove aliases community.general#1470
• nios_member: fix nios api member_normalize error with python 3 community.general#1527
• Tidy up validate-modules ignores for modules: net_tools/nios community.general#1598

For one of these (1470), there exists a PR in the infoblox repo (infobloxopen/infoblox-ansible#28) which never got any attention. And quite a few of these PRs fix various sanity errors that were ignored before.

I think it would make sense to take a lot of these changes and apply them to the infoblox repo.

[anagha-infoblox]

We will look into it and apply the changes to the infoblox repo. Thank you.

[felixfontein]

I currently do not see any work on this in the collection repository, or am I missing something?

[anagha-infoblox]

There are no changes made w.r.t. the above yet. As of now we have implemented the suggestions given in the following comment- #11 (comment) to make our code compliant to Ansible 3.0.0 release. We'll try to review the above and implement soon.
Thank you.

[felixfontein]

There are at least two bugfixes you should really take a look at: ansible-collections/community.general#1527 infobloxopen/infoblox-ansible#28

[anagha-infoblox]

Hi,

The following suggestions are addressed and release as a new version 1.0.2:

1. Added tags for the previous releases
2. Fixed the sanity tests which were required but ignored in the previous release
3. The CI test is passed
4. Removed the following file: https://github.com/infobloxopen/infoblox-ansible/blob/master/ansible_collections/infoblox/nios_modules/plugins/.DS_Store

Ansible Galaxy: https://galaxy.ansible.com/infoblox/nios_modules
GitHub repo: https://github.com/infobloxopen/infoblox-ansible
Issue tracker: https://github.com/infobloxopen/infoblox-ansible/issues
Contacts: @Vaishnavi-infoblox or @anagha-infoblox

[abadger]

Just a note. The deadline for new collections to be accepted was today, 27-01-2021, but we voted at today's community irc meeting to extend that to Friday:

• infoblox.nios_modules has until Friday to be approved for 3.0 but will not block the ansible-3.0 release.
• If not approved by Friday, it will target ansible-4 for inclusion instead.

[gundalow]

@Vaishnavi-infoblox @anagha-infoblox We feel it's annoying & confusing to both users and maintainers that there are two copies of nios modules around (community.general & infoblox.nios). Therefore we've made the decision to deprecate the nios content in community.general (for removal in community.general 5.0.0, i.e. in a year) where the deprecation message says to use the corresponding content from infoblox.nios_modules instead.

What do you believe is on the todo list to get infoblox.nios up to standard? We really want to get your collection in ansible==5.0.0, which means having this complete in the next 3 months.

As always the Community is available to help guide you through this process, so please ask if you have any questions.

[saileshgiri]

@gundalow yes, that'd be confusing and we'd like to have infoblox.nios_modules as the single source. The team will merge the PRs from community.general that are currently missing in infoblox.nios_modules. The infoblox.nios_modules was created with community.general as the source so I believe there will not be many such PRs.
We'd definitely like to be considered for 5.0.0 and we'll complete this merge within that timeframe. Please let me know if there is any other change that's required from our team related to this and we'll plan the task. Thanks again for all the feedback and help

[gundalow]

@saileshgiri @Vaishnavi-infoblox @anagha-infoblox How are you progressing with the collection

1. Infoblox.nios_modules inclusion #11 (comment) is the main list of what needs doing
2. You need to manually move all the updates from community,.general into your collection

Please see the Ansible 5.0.0 roadmap, in particular

• (AN) 2021-10-12 - last day for new collections to be submitted for inclusion in ansible-5. Note that collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion.
• (AN) 2021-10-25 - last day for new collections to be approved for inclusion in ansible-5
• (AN) 2021-10-25 - last day for collections to make backwards incompatible releases that will be accepted into Ansible-5.

Although these dates may appear to be a while away, they will arrive sooner, and everybody needs time to review the collection and fixes made.

[anagha-infoblox]

@gundalow We have started moving all the updates from community.general to our collection. We'll start addressing the comments as well shortly and submit for review in prior.

[anagha-infoblox]

@gundalow We have implemented all changes from the community general. As of now the changes are present in the develop branch- https://github.com/infobloxopen/infoblox-ansible/tree/develop. We'll be merging this branch to the master once we provide a few more bug fixes.

[anagha-infoblox]

Hi @felixfontein, @tadeboro, @gundalow, @dmsimard,

We have implemented all the changes from the community.general and have addressed most of the suggestions provided previously in this discussion. As of now, the changes are present in the develop branch- https://github.com/infobloxopen/infoblox-ansible/tree/develop. We will be merging this branch to the master once we address all the suggestions and provide a few more bug fixes. The changes are going to be merged in the last week of August.
I had a query regarding the review process:
Will the code be reviewed from the master branch of the GitHub repository?

[gundalow]

@anagha-infoblox Looks like develop hasn't been merged into master yet infobloxopen/infoblox-ansible@master...develop

1. Could you please merge develop into `master
2. Make a new release to Ansible Galaxy

[anagha-infoblox]

@gundalow We found a few bugs that need to be fixed before the next release. We will make a new release on the galaxy in the first week of September after fixing those bugs. Do let us know if we have to expedite the process and make a release before September first week.

[tadeboro]

September should be OK since the submission deadline is in October: https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/COLLECTIONS_5.rst#release-schedule But the sooner the better ;)

[anagha-infoblox]

Hi @tadeboro,
We have made a new release with all the bug fixes and a few minor features on the GitHub. But, we are facing some issues while publishing it on the Ansible Galaxy. We need your help to fix the issue.
Getting the following error while publishing:
Publishing collection artifact '/home/akh/infoblox-ansible/ansible_collections/infoblox/nios_modules/infoblox-nios_modules-1.1.1.tar.gz' to default https://galaxy.ansible.com/api/ ERROR! The collection path specified '/home/akh/infoblox-ansible/ansible_collections/infoblox/nios_modules/infoblox-nios_modules-1.1.1.tar.gz' does not exist.
Note: The .tar.gz file is present in the path. It was generated using the command ansible-galaxy collection build.

[anagha-infoblox]

Hi @tadeboro,
We were successfully able to publish the collections v1.1.1 on the Ansible Galaxy.
Please review the same.

Thank you

[felixfontein]

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.

General comments:

• MUST FIX It is totally unclear to me what's the difference between the develop and the master branch in the repository. The develop branch seems to be out-of-date (it doesn't contain the latest release for example) and isn't mentioned anywhere in the documentation (that I found). If it's no longer required, please delete it. Otherwise, please document it somewhere. In the following, I'll review the state of the master branch, since it seems to be the current development version.
• SHOULD FIX Integration testing: while you have some files that look like integration tests (https://github.com/infobloxopen/infoblox-ansible/tree/develop/ansible_collections/infoblox/nios_modules/tests/integration/targets), these are not run in CI (there's no integration test part in https://github.com/infobloxopen/infoblox-ansible/blob/develop/.github/workflows/ansible-test.yml). On the other hand, community.general has a whole list of nios integration tests (see nios_* in https://github.com/ansible-collections/community.general/tree/main/tests/integration/targets/) that run in CI and work well. You should really copy these over and make sure they run in CI!
• SHOULD FIX Unit testing: community.general has a whole list of nios unit tests (https://github.com/ansible-collections/community.general/tree/main/tests/unit/plugins/module_utils/net_tools/nios, https://github.com/ansible-collections/community.general/tree/main/tests/unit/plugins/modules/net_tools/nios) that run in CI and work well. You should really copy these over and make sure they run in CI!

Public availability and communication:

• published on 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
  SHOULD FIX Please use complete sentences in descriptions (other than short_description). For example, "username" is not a full sentence, and "restrict returned hosts by extensible attributes" isn't either.
  SHOULD FIX Plugin option documentation should always provide type for every option.
• 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
    MUST FIX For the inventory plugin, there is some confusion what the plugin name should be. The filename indicates infoblox.nios_modules.nios_inventory; DOCUMENTATION indicates infoblox.nios_modules.Inventory; and InventoryModule.name indicates infoblox. The correct value is very likely infoblox.nios_modules.nios_inventory, and the other values have to be adjusted to match this one (name in DOCUMENTATION must be just the last component, i.e. nios_inventory).
    MUST FIX The inventory plugin contains a print() call.
• 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
  MUST FIX The inventory plugin's example uses a non-FQCN for the plugin options value.
• 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]

There is nothing special about running tests in the CI environment. For integration tests, you need to run the ansible-test integration --docker --python <selected python version here> --remote-state prod --remote-terminate always, and for unit tests, you run ansible-test units --docker. How you integrate these two commands into your CI depends on what provider you intend to use. https://github.com/ansible-collections/collection_template/blob/main/.github/workflows/ansible-test.yml contains sample configuration for GitHub Actions.

[anagha-infoblox]

Hi @tadeboro, @felixfontein,
We were able to release and publish NIOS modules v1.1.2 successfully. The review comments suggested have been addressed in this release.
Thank you for the guidance.

[felixfontein]

I've taken another look at the collection, I think it looks pretty good now. The only thing I noticed is that it doesn't run tests against stable-2.12 yet; while the final version of ansible-core 2.12 hasn't been released yet, it's a good idea to run tests against it as well to see whether there are potential problems coming up - in particular since Ansible 5 will be based on ansible-core 2.12.

[anagha-infoblox]

Sure. I've raised a Pull Request to support the same. Should we release a new version on GitHub and Galaxy after the merge with this minor change?

[felixfontein]

Thanks! No, a new release isn't necessary, since this doesn't affect anything user-visible in the released collection.

[tadeboro]

Thank you for your submission, @Vaishnavi-infoblox.

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 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
  SHOULD FIX: Modules do not document their return values.
• 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]

As far as I am concerned, this collection is ready for inclusion in Ansible 5.0.0. Thank you, @Vaishnavi-infoblox, for your effort!

[anagha-infoblox]

Thank you @tadeboro for the guidance! We will address the review comment of adding return values to the modules in our next release.
@Vaishnavi-infoblox is no longer working with us in the organization. For any queries please reach out to me.
Github username- @anagha-infoblox
email- [email protected]
Thank you

[gundalow]

I know it's been a long process to get here, though I'm so glad it's paid off. The amount of discussion and help he is great to see. I believe you've ended up with a great collection.

Thank you to everybody that's been involved in this.

[tadeboro]

The community members accepted the infoblox.nios_modules collection into Ansible 5 (ansible-community/ansible-build-data#73). Thank you all for your patience and cooperation.

[felixfontein]

ansible-collections/community.general#3592 removes the (deprecated) infoblox content from community.general and replaces it with (non-deprecated) redirects to infoblox.nios_modules.

[gundalow]

Once this is all happy and included in a released version of ansible the redirects in ansible-core will need updating to point directly to the new collection rather than c.general

[anagha-infoblox]

Hi,
A contributor to the infoblox.nios_modules is facing an issue while executing the integration tests written. The error is as depicted in the link: https://github.com/infobloxopen/infoblox-ansible/runs/4060774168?check_suite_focus=true#step:7:719. Is it not possible to test nios_nsgroup or nios_nsgroup_delegation using the nios-simulator image? Please let us know if any changes have to be made on our end.

Thank you

[felixfontein]

I'm not sure whom you are asking here (this is not a support forum), but you might want to look into the simulator's code: https://github.com/ansible/nios-test-container

[anagha-infoblox]

Thank you. I will take a look at the code.

[anagha-infoblox]

Hi,
The sanity tests for stable 2.11 is failing with the following error: ERROR: Command "/root/ansible_collections/infoblox/nios_modules/tests/output/.tmp/sanity/import/minimal-py37-requirements-8b83ca76b13364be2f9e02cfcf77dd0bd86a1921ca9e121049d8db49f04fa29b/bin/python /root/ansible/test/lib/ansible_test/_data/quiet_pip.py install --disable-pip-version-check -r /root/ansible/test/lib/ansible_test/_data/requirements/sanity.import-plugins.txt -c /root/ansible/test/lib/ansible_test/_data/requirements/constraints.txt" returned exit status 1.
Please let us know if any changes have to be made on our end.

Thank you

[Andersson007]

please ignore it