Include ansible.utils collection

[ganeshrn]

Repo: https://github.com/ansible-collections/ansible.utils
Galaxy: https://galaxy.ansible.com/ansible/utils
Owners: ganeshrn, cidrblock, pabelanger

[tadeboro]

Hi @ganeshrn.

The community has agreed on a list of criteria that must be met to move forward with the inclusion of a collection in the Ansible package. For this discussion, we will use a shortened checklist to verify and record compliance, but you can find the full details in the Collection Requirements documentation.

This is a new and gradual process, and we will edit this comment as we progress along. 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.

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
  Comment: I could not find this information in the repo. Is this information available somewhere else?
• have a Code of Conduct (CoC) compatible with the Ansible Code of Conduct (CoC)
  Comment: README file does explicitly states that collection follows Ansible's CoC, but this file is not present in the repo.
• have a publicly available issue tracker that does not require a paid level of service to create an account or view issues

Standards and documentation:

• adheres to semantic versioning
• follows licensing rules
• follows the Ansible documentation standards and the style guide
• follows development conventions
• 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
• meta/runtime.yml defines the minimal version of Ansible which the collection works with
  Comment: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#metaruntimeyml suggests that collections do not specify an upper bound on Ansible version.
• 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
  Comment: Is there a reason for keeping the code that needs ignore entry in the plugins/module_utils directory? Since this collection is already using non-standard collection directories, it may as well put this code into plugins/plugin_utils or somewhere similar and keep the ignore files clean.
• has CI tests up and running against each of the "major versions" of ansible-base/ansible-core that the collection supports
  Comment: It seems that sanity tests are only executed against Ansible 2.9 on Python 3.6.
• 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)
  Comment: Judging by the job list at the https://dashboard.zuul.ansible.com/t/ansible/builds?job_name=ansible-test-sanity-ansible-utils, test are only run when something changes or new release is created.

General notes:

This collection uses (abuses?) the fact that Ansible does not verify the collection's structure and uses non-standard directories to store code (plugins/{cli_parsers,fact_diff,validate}).

[tadeboro]

has a policy of releasing, versioning and deprecation announced to contributors and users in some way
Comment: I could not find this information in the repo. Is this information available somewhere else?

For policy on releasing and versioning, I will get back with more details. For deprecation notices, we will rely on adding the message in the runtime.yml file and the information will also be part of the changelog file.
The announcement of the release of this collection is Automated with Twitter notification. Please refer the announcement for recent release here https://twitter.com/AnsibleContent/status/1336382208890654721

Great to hear that. Maybe some of this information can be added to the README file so it is easier to find? It does not have to be much, something as simple as https://github.com/ansible-collections/community.general#roadmap is enough.

have a Code of Conduct (CoC) compatible with the Ansible Code of Conduct (CoC)
Comment: README file does explicitly states that collection follows Ansible's CoC, but this file is not present in the repo.

Is it expected for the Code of Conduct document to be part of the repository? This repository will be maintained mainly by Ansible content team and will continue to adhere to Ansible CoC hence IMO it is better to have a link referencing the right document instead of duplicating it in the ansible.utils repository.

I am not sure about this one, but the current checklist assumes the CoC file is inside the collection repo. I did add https://github.com/ansible-collections/community.general#roadmap to the meeting agenda for clarification. If I were to decide, having a link to the source CoC document would be enough (or even better since there is no need to keep things in sync).

passed ansible-test sanity
Comment: sanity tests do pass locally, but I could not find what CI/CD system collection uses to run tests. Is it possible to see test run results from the CI/CD?
has CI tests up and running against each of the "major versions" of ansible-base/ansible-core that the collection supports
Comment: I cannot verify this because there is no mention of CI/CD in the repo.
all CI tests run against every pull request
Comment: I cannot verify this because there is no mention of CI/CD in the repo.
all CI tests run against a commit that releases the collection; if they don't pass, the collection won't be released
Comment: I cannot verify this because there is no mention of CI/CD in the repo.
all CI tests run regularly (nightly, or at least once per week)
Comment: I cannot verify this because there is no mention of CI/CD in the repo.

The repository is integrated with Zuul CI and all the check and gate jobs that run for each PR prior to the merge can be seen on the Zuul project page here https://dashboard.zuul.ansible.com/t/ansible/project/github.com/ansible-collections/ansible.utils

Thanks for this info. But even with this link, it took me quite a while to find the right information since some of the Zuul things seem to be stored in private git repositories. But after some clicking, I did manage to find:

• https://dashboard.zuul.ansible.com/t/ansible/buildset/bd5324c35da94e43a56a2261bc5eb87e, which led me to
• https://dashboard.zuul.ansible.com/t/ansible/build/9ab9662e9fea4ee8b178a14881f25072, where I found
• https://4aabeb28b72819200a73-f051d4657bca2b35b3e62c987399342b.ssl.cf5.rackcdn.com/31/4de8734bb1d55f444219b3740c32a296fd1be2df/gate/ansible-test-sanity-ansible-utils/9ab9662/ara-report/#

After combining the information from the run.yaml playbook from the last link and info from https://dashboard.zuul.ansible.com/t/ansible/job/ansible-test-sanity-ansible-utils and https://dashboard.zuul.ansible.com/t/ansible/job/ansible-test-sanity-base-29 gives me an impression that sanity tests are only executed on Python 3.6 and Ansible 2.9. Can you confirm this or show me where did I go wrong in my research? Thank you in advance.

[felixfontein]

have a Code of Conduct (CoC) compatible with the Ansible Code of Conduct (CoC)
Comment: README file does explicitly states that collection follows Ansible's CoC, but this file is not present in the repo.

Is it expected for the Code of Conduct document to be part of the repository? This repository will be maintained mainly by Ansible content team and will continue to adhere to Ansible CoC hence IMO it is better to have a link referencing the right document instead of duplicating it in the ansible.utils repository.

I am not sure about this one, but the current checklist assumes the CoC file is inside the collection repo. I did add https://github.com/ansible-collections/community.general#roadmap to the meeting agenda for clarification. If I were to decide, having a link to the source CoC document would be enough (or even better since there is no need to keep things in sync).

The way I read the checklist (both the short and the long one) the collection needs a CoC, but it must not necessarily be a file with the complete content. A link should be fine. That's also what most existing collections do (that I know of), and what the 'official' template does (https://github.com/ansible-collections/collection_template/blob/main/CODE_OF_CONDUCT.md).

[tadeboro]

I am not sure about this one, but the current checklist assumes the CoC file is inside the collection repo. I did add https://github.com/ansible-collections/community.general#roadmap to the meeting agenda for clarification. If I were to decide, having a link to the source CoC document would be enough (or even better since there is no need to keep things in sync).

The way I read the checklist (both the short and the long one) the collection needs a CoC, but it must not necessarily be a file with the complete content. A link should be fine. That's also what most existing collections do (that I know of), and what the 'official' template does (https://github.com/ansible-collections/collection_template/blob/main/CODE_OF_CONDUCT.md).

The thing that "bothered" me is the fact that the link is inside the README.md file. So when one hits the repo for the first time, it looks like CoC is not there. But as stated before, I would approve the things the way they are, but the repo layout deviates just enough that I am not 100% sure if this is for me to decide.

[pabelanger]

has a policy of releasing, versioning and deprecation announced to contributors and users in some way
Comment: I could not find this information in the repo. Is this information available somewhere else?

For policy on releasing and versioning, I will get back with more details. For deprecation notices, we will rely on adding the message in the runtime.yml file and the information will also be part of the changelog file.
The announcement of the release of this collection is Automated with Twitter notification. Please refer the announcement for recent release here twitter.com/AnsibleContent/status/1336382208890654721

Great to hear that. Maybe some of this information can be added to the README file so it is easier to find? It does not have to be much, something as simple as ansible-collections/community.general#roadmap is enough.

have a Code of Conduct (CoC) compatible with the Ansible Code of Conduct (CoC)
Comment: README file does explicitly states that collection follows Ansible's CoC, but this file is not present in the repo.

Is it expected for the Code of Conduct document to be part of the repository? This repository will be maintained mainly by Ansible content team and will continue to adhere to Ansible CoC hence IMO it is better to have a link referencing the right document instead of duplicating it in the ansible.utils repository.

I am not sure about this one, but the current checklist assumes the CoC file is inside the collection repo. I did add ansible-collections/community.general#roadmap to the meeting agenda for clarification. If I were to decide, having a link to the source CoC document would be enough (or even better since there is no need to keep things in sync).

passed ansible-test sanity
Comment: sanity tests do pass locally, but I could not find what CI/CD system collection uses to run tests. Is it possible to see test run results from the CI/CD?
has CI tests up and running against each of the "major versions" of ansible-base/ansible-core that the collection supports
Comment: I cannot verify this because there is no mention of CI/CD in the repo.
all CI tests run against every pull request
Comment: I cannot verify this because there is no mention of CI/CD in the repo.
all CI tests run against a commit that releases the collection; if they don't pass, the collection won't be released
Comment: I cannot verify this because there is no mention of CI/CD in the repo.
all CI tests run regularly (nightly, or at least once per week)
Comment: I cannot verify this because there is no mention of CI/CD in the repo.

The repository is integrated with Zuul CI and all the check and gate jobs that run for each PR prior to the merge can be seen on the Zuul project page here dashboard.zuul.ansible.com/t/ansible/project/github.com/ansible-collections/ansible.utils

Thanks for this info. But even with this link, it took me quite a while to find the right information since some of the Zuul things seem to be stored in private git repositories. But after some clicking, I did manage to find:

• dashboard.zuul.ansible.com/t/ansible/buildset/bd5324c35da94e43a56a2261bc5eb87e, which led me to
• dashboard.zuul.ansible.com/t/ansible/build/9ab9662e9fea4ee8b178a14881f25072, where I found
• 4aabeb28b72819200a73-f051d4657bca2b35b3e62c987399342b.ssl.cf5.rackcdn.com/31/4de8734bb1d55f444219b3740c32a296fd1be2df/gate/ansible-test-sanity-ansible-utils/9ab9662/ara-report/#

After combining the information from the run.yaml playbook from the last link and info from dashboard.zuul.ansible.com/t/ansible/job/ansible-test-sanity-ansible-utils and dashboard.zuul.ansible.com/t/ansible/job/ansible-test-sanity-base-29 gives me an impression that sanity tests are only executed on Python 3.6 and Ansible 2.9. Can you confirm this or show me where did I go wrong in my research? Thank you in advance.

There is nothing stored in private git repos, our CI is all public. The main 2 repos for the CI is:

https://github.com/ansible/project-config
https://github.com/ansible/ansible-zuul-jobs

As for sanity jobs, yes right now we do python36 and stable-29, we do this because this is what automation hub supports. We do plan to bump this to python38 / ansible 2.11 for execution environments.

[tadeboro]

There is nothing stored in private git repos, our CI is all public. The main 2 repos for the CI is:

https://github.com/ansible/project-config
https://github.com/ansible/ansible-zuul-jobs

As for sanity jobs, yes right now we do python36 and stable-29, we do this because this is what automation hub supports. We do plan to bump this to python38 / ansible 2.11 for execution environments.

When I was clicking through the Zuul interface, I stumbled upon a few 404 responses from GitHub, which often means the linked repo is private. But in this case, it turned out that github.com/ansible/ansible-zuul-jobs/playbooks/ansible-test-base/run.yaml from https://dashboard.zuul.ansible.com/t/ansible/build/9ab9662e9fea4ee8b178a14881f25072/console is not really a link that one would expect to work. So this is my bad for not looking close enough.

[felixfontein]

Question (already asked here, but so far no reply): why is the changelog RST file inside the changelogs/ directory, and not in the collection root?

[pabelanger]

Again, this isn't a restriction, this is the first time we are going through this process. Things can change. I am asking you to see it from our side, we a community collection need to support 2 enforcement policies. One here, in ansible community and one for automation hub. All collection owners, that need to support both platforms, will need to do this process. And I am asking, that the community team and galaxy / AH team sit down to understand both requirements. Maybe even enforce the same standards.

So, given the document doesn't reference Python versions, then we are okay? I can understand your personal objection to it, which is what I am trying to figure out. We picked python36 for the simple reason, is that is what centos-8 shipped with at the time the job was created. With execution environments on the way, we will likely bump this to python38. Again, we can add more then 1 python version, that isn't the issue, but from a policy point of view, having the version be explicit is very helpful.

Again, we don't limit to a single version, we run unit tests and integration tests again multiple python versions.

[tadeboro]

The reason why we run py36 / stable-2.9 is because that is what Automation hub enforces, it does not even include 2.10. It would be great if the community team, worked with galaxy / AH team to enable this.

Also, no where in your document do you describe the version of Python to be tested (this could be hidden under 'sanity'). Again, we use python36 (soon to be python38) to preparation for execution environments. Again this can be changed.

Last time I checked AH runs sanity tests on all python versions in the default testing container (we had to add quite a few ignore entries to our collection because we do not support Python 2.6 and AH import process always tests this). It is true that it is using Ansible 2.9 because that is what you can buy support for, but they do not limit python versions.

[pabelanger]

yes, you are right. I misspoke about python36 being the only version. it is only stable-2.9 that is tested

[felixfontein]

Ah, so you run the 2.9 sanity tests for all Python versions (using the default docker container)? That's totally fine. Except that it's just the Ansible 2.9 sanity tests, and not the more important ansible-base 2.10 sanity tests (after all Ansible 3.0.0 is based on ansible-base 2.10).

[tadeboro]

No, AH runs those sanity tests on import. Zull only uses Ansible 2.9 and Python 3.6 to run sanity tests. At least this is what I can deduce from the logs at https://dashboard.zuul.ansible.com/t/ansible/build/9ab9662e9fea4ee8b178a14881f25072/console. Grepping for with Python only finds 3.6.

[felixfontein]

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
  • Comment: cannot find information on this.
• 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

Standards and documentation:

• adheres to semantic versioning
• follows licensing rules
  • Comment: some files say "Copyafter 2020 Red Hat".
• follows the Ansible documentation standards and the style guide
  • Comment: plugins/modules/fact_diff.py option plugin.vars.skip_lines and return value diff_lines uses type: list, but not elements: ... to indicate the list element type. (Also happens in other files.)
  • Comment: plugins/modules/validate.py uses C(...) for option names data and criteria. This also happens in other files, like in plugins/validate/jsonschema.py
• follows development conventions
• 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
  • Comment: plugins/cli_parser/json_parser.py uses lookup('file', ... instead of lookup('ansible.builtin.file', .... Same for textfsm_parser, ttp_parser, xml_parser in the same directory.
  • Comment: plugins/filter/index_of.py uses set_fact:, debug: without ansible.builtin. prefix.
  • Comment: plugins/filter/to_paths.py uses uri: without ansible.builtin. prefix.
  • Comment: plugins/filter/validate.py uses set_fact: without ansible.builtin. prefix in one case.
  • Comment: plugins/lookup/index_of.py uses set_fact:, debug: without ansible.builtin. prefix.
  • Comment: plugins/lookup/to_paths.py uses uri: without ansible.builtin. prefix.
  • Comment: plugins/lookup/validate.py uses set_fact: without ansible.builtin. prefix in one case.
  • Comment: plugins/modules/fact_diff.py uses set_fact: without ansible.builtin. prefix in one case.
  • Comment: plugins/modules/update_fact.py uses set_fact:, debug: without ansible.builtin. prefix.
  • Comment: plugins/modules/validate.py uses set_fact: without ansible.builtin. prefix in one case.
  • Comment: plugins/test/validate.py uses set_fact: without ansible.builtin. prefix in one case.
• 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
• 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
  • Comment: it is also unclear to me whether sanity tests are run for both Ansible 2.9 and 2.10.
• 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)
  • Comment: not clear to me.

[pabelanger]

• all CI tests run regularly (nightly, or at least once per week)

  • Comment: not clear to me.

We currently don't do this, given we gate every commit via Zuul (zuul handles merges) all tested must pass before code can be merged. This puts us in the position to depend on pre-merge testing over post merge testing.

[felixfontein]

BTW, here is an updated (clarified) version of the requirements on sanity tests that was approved by the community meeting: https://github.com/ansible-collections/overview/pull/147/files#diff-dacab21f27a6aa218b8dcaafcf6f5685df0ab52f231afa16e7a9ab5284b72c68R192

[pabelanger]

I started to think more about this last night, with how we plan to base testing on execution environments. Given that ansible 2.11 and 2.12 are python38 only. How does that play into community collections.

We are seriously considering only supporting python38 for network collections, given ansible-core has move this way. Do we explicitly say, a collection MUST support all python versions?

[felixfontein]

You should still make sure that ansible-test sanity --docker will run through, no matter what you require or what you test against in CI, by adding the correct set of ignore.txt entries. (Once ansible-test has support for per-collection config files that allow to specify which Python versions are supported the ignore.txt entries can go, but until then they are needed, and also for the ansible-base/-core versions that don't have support for these configs.)

What you should watch out for is collection requirements. From what I gathered in ansible-community/ansible-build-data#42, ansible.utils will be a dependency of ansible.netcommon 2.0.0, which in turn is a requirement of many network collections. I don't know which parts of ansible.netcommon will depend on ansible.utils, but in the worst case you would force all modules from all network collections to require Python 3.8 or newer.

(If ansible.utils is not included in Ansible 3.0.0, we will have to restrict ansible.netcommon to <2.0.0. I don't think that's really desirable either.)

[ganeshrn]

I don't know which parts of ansible.netcommon will depend on ansible.utils

The cli_parse module and relevant cli_parse plugins are moved from netcommon collection to utils collection as it is a generic module and not specific to networking.

but in the worst case you would force all modules from all network collections to require Python 3.8 or newer.

The supported network collections will require to support all the python versions that are supported by ansible-base on control node

(If ansible.utils is not included in Ansible 3.0.0, we will have to restrict ansible.netcommon to <2.0.0. I don't think that's really desirable either.)

In addition to above, all the supported network collection (and some security) collection have a dependency on netcommon collection so all those collections will restrict to < 2.0.0 which will be an unfortunate scenario

[ganeshrn]

@felixfontein AFAIK community.network has a dependency on ansible.netcommon for connection bits, not sure why that dependency is not added in the galaxy.yml file of community.network?

[felixfontein]

@ganeshrn it is there: https://github.com/ansible-collections/community.network/blob/main/galaxy.yml#L12

[ganeshrn]

@felixfontein My bad..I missed that line :-)

[pabelanger]

You as a maintainer can decide to only support one python version, but I am afraid that by doing this your collection would become so different from the rest of the community content that it would make little sense to have it included in something that tries to be a general-purpose distribution of Ansible content.

Is this officially documented, or personal opinion? Again, I am trying to get to a point, where we can look to the guidelines and be explicit on what is supported or not. None of this on our-side is set in stone, and we have the ability increase coverage. So far, we are told we can pick any version of python to support, in our discussion that is python38 per ansible-core. Yet, also told makes little sense to be included in ansible 3.0.0 now.

I would personal like to see, if we as collections owners okay with picking our own version of python, then limit sanity to also be that same version of python to be ran. It makes little sense, to still run python 2.7 or python 3.6 sanity, if un-supported in the collection.

[pabelanger]

• Modules must continue to support python-2.6+ and python-3.5

Thank you version much for the detailed reply. Given what you'd shared, I think the idea of a collection owner getting to choose the version of python they support, isn't really true. Unless under the very specific scenario you've listed above. Given that the current collections docs say:

Collections can choose to skip certain Python versions that they explicitly do not support; this needs to be documented in README.md and in every module and plugin (hint: use a docs fragment).

I look forward to the updates @Ompragash will propose.

And, thank you for walking though the process a little more. I think we can go back on our side, re-read the comments here, then really decided what python we can support, and why.

[ganeshrn]

@abadger

ansible-core-2.11 (and therefore, ansible-4.0) will continue to run with python-2.7 and python-3.5+ on the controller. It's just "support" which they are dropping.

Which version of ansible-core will be bundled with ansible-3.0.0, will it be 2.10?

Also note, the controller-module split is really a process split. Filter, test, inventory, callback plugins are loaded by ansible/ansible-playbook and thus they run with the same interpreter as the scripts. Modules are run in a separate process. I do not know if all the networking plugins are also run in the same process or if they're spawned off into a separate process so I don't know whether they are more like "plugins" or "modules" for this specific discussion.

The networking module uses connetion=local under the hood and are spawned in a separate process. However, since the module executes on the control node itself the python version requirement is kept same as that of ansible engine (unless the module code has exception in which case it is documented in module doc).

The ansible.utils collection for which we are discussing here is independent of network use case and currently, since there is no module side code all the plugins are executed on the control node itself.

[felixfontein]

@ganeshrn Ansible 3.0.0 comes with ansible-base 2.10. See here for the current schedules for Ansible 3.0.0 and 4.0.0.

[abadger]

The networking module uses connetion=local under the hood and are spawned in a separate process. However, since the module executes on the control node itself the python version requirement is kept same as that of ansible engine (unless the module code has exception in which case it is documented in module doc).

This is not obviously correct (and not obviously incorrect either. Afaik, the ansible-core code which this revolves around has not been merged yet) Nitzmahone has said that he is changing the way Ansible works so that modules run on the controller either can or will use the system python as opposed to the python which invokes the scripts.

[ganeshrn]

I am not sure what you are referring to but in case of network modules it is recommended to set the ansible configuration variable to point the the same python that is used by the ansible-core

[ganeshrn]

@tadeboro @felixfontein Thanks for reviewing the collection and providing the comments. I have fixed doc related comments in PR ansible-collections/ansible.utils#32. Please review it.

[felixfontein]

I'm starting a new thread so this won't get forgotten: the collection still does not run the ansible-base 2.10 sanity checks (see ansible-collections/ansible.utils#33 (comment)).

(To clarify: this is a REQUIREMENT for inclusion in 3.0.0 and for me a BLOCKER if not satisfied.)

[felixfontein]

That's now changed.

[ganeshrn]

There were concerns raised around the mention of cli_parse module in network plugin developer guide here. To clarify on this the current developer guide for this is for ansible.netcommon.cli_parse module which will be deprecated in favour of ansible.utils.cli_parse module by PR ansible-collections/ansible.netcommon#182 and will go through a deprecation cycle of 2 years along with warning message and it will remain backwards compatible for the current structure for the period of deprecation. The developer guide will be updated after the ansible.utils 2.0.0 collection is released with this information and will point to use ansible.utils.cli_parse module from ansible.utils>=2.0.0 version along with more detailing explanation and examples. The ansible.utils 2.0.0 release which will have a permanent collection sub-plugin structure as discussed here and will encourage the correct usage of custom (sub) plugins within collections.

[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:

• ansible.utils has until Friday to be ready for another review.
• Reviewers can approve or say not ready by 2-2.
• If it's not approved by 2-2, it has to go to ansible-4 instead (and then we'll have to figure out what dependent collections cannot be updated either)

[ganeshrn]

I have pushed the changelog for 2.0.0 and the collection is ready for review.
@NilashishC will release the collection version 2.0.0 later in the day, currently, all the network collections release is put on hold due to a blocking issue with AH for automated releases.

[NilashishC]

ansible.utils:2.0.0 has been uploaded to Galaxy.

[ganeshrn]

@NilashishC Thank you!

[felixfontein]

I've taken another look at the collection, looks good for inclusion for me!

Sorry, I missed the fact that sanity tests are only run with Python 3.8. That's clearly not enough.

[ganeshrn]

The test matrix for the collection as on today is:

Integration test:
Ansible: devel, stable-2.10, stable-2.9
Python: 3.6, 2.7

Unit test:
Ansible: devel, stable-2.10, stable-2.9
Python: 3.8, 3.7, 3.6, 3.5, 2.7


Sanity test:
Ansible: devel, stable-2.10, stable-2.9
Python: 3.8

The results for unit and integration tests are publicly available with very good code coverage (unlike some other collections in the list :-)) and this should give a high level of confidence in code quality, especially from the end-users perspective.

As @pabelanger mentioned in the comment here we are working on adding more python versions for sanity test which should be ready by next week.

Considering the extensive test coverage in unit and integration test with different python version the lack of sanity test for other python versions shouldn't be considered as a blocking issue for Ansible 3.0.0 inclusion IMO.

[cidrblock]

@ganeshrn Nicely done on the test code coverage! I see ansible.utils is at 98.9%. I wan't able to find the inclusion criteria bar but I'm sure this meets it. https://app.codecov.io/gh/ansible-collections/ansible.utils

[tadeboro]

Since the code quality is excellent and sanity testing changes are on the way, I approve the inclusion of this collection in Ansible 3.0.0

[felixfontein]

I agree, as long as proper sanity testing is added soon (in say at most a week or so).

[abadger]

I need to know some githb ids for the maintainer/owners of this collection to add it to the ansible package.

[pabelanger]

Using the top 2 in https://github.com/ansible-collections/ansible.utils/graphs/contributors should work.

[ganeshrn]

@tadeboro @felixfontein @Andersson007 @abadger @gundalow @NilashishC @pabelanger @cidrblock Thank you all for the reviews and the work on this collection. IMO the collection is in a better state today as compared to that of before opening up this discussion and hopefully, all the discussions around it helped improve the process of community inclusion :-)

[abadger]

This has now been added for the ansible-3 release.