New collection: kubevirt.core

[0xFelix]

Lean Ansible bindings for KubeVirt, which provide virtual machine operations and an inventory source for use with Ansible.

Ansible Galaxy: https://galaxy.ansible.com/kubevirt/core
GitHub: https://github.com/kubevirt/kubevirt.core
Issues Tracker: https://github.com/kubevirt/kubevirt.core/issues
GitHub Handles: @0xFelix @guidograzioli
Is the collection part of Automation Hub: Yes -> redhat.openshift_virtualization
We meet Collection Requirements: Yes

[Andersson007]

@0xFelix hi, thanks for submitting the request! The @ansible-collections/steering-committee will review it as soon as someone has time

[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
• has a policy of releasing, versioning and deprecation announced to contributors and users in some way
  MUST FIX: not found
• 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 this repository

Standards and documentation:

• adheres to semantic versioning
  MUST FIX Doesn't follow SemVer. Please read it carefully and put a link to SemVer specification to your readme. We release modules as a minor change, not as a major/breaking change https://github.com/kubevirt/kubevirt.core/blob/main/CHANGELOG.rst#v110 Mostly breaking (backward incompatible) changes ship in major release. A new plugin doesn't break users playbooks.
• follows licensing rules
• follows the Ansible documentation standards and the style guide
• follows development conventions; as well as these other requirements:
  • modules satisfy the concept of idempotency
  • 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 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)
  QUESTION: Why does the collection not support Python 2.7 on a target? Are there any objective obstacles for it?
• 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 (except cases when they were added in the very first release of the collection)
• FQCNs are used for extends_documentation_fragment:, unless you are referring to doc_fragments from ansible-core
• 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.11, - stable-2.12, - stable-2.13.
• 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
• 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
• all CI tests MUST run against every pull request
• all CI tests MUST run regularly (nightly, or at least once per week)
• sanity tests MUST run against a commit that releases the collection; if they don't pass, the collection won't be released

[Andersson007]

@0xFelix i've done the first round of review. Please take a look at check boxes with no checks

[0xFelix]

Thanks for the review @Andersson007!

Regarding your comments:

• The release policy lives in https://github.com/kubevirt/kubevirt.core/blob/main/docs/releasing.md. I'll make sure to put a link into the README.md.
• I'll adjust the changelog, so the new module is considered a minor change.
• It does not support Python 2.7 since it relies on kubernetes.core which neither supports Python 2.7. The plugins and README.md already state the required/tested Python versions.

[0xFelix]

Fixes can be found here: kubevirt/kubevirt.core#68

@Andersson007 Can you give this another look? Thank you!

[Andersson007]

@0xFelix cool, thanks, lgtm, how about also to include the link to SemVer I mentioned in that MUST FIX ?

[Andersson007]

Ah, i see it in the docs, please ignore the comment ^, thanks!

[Andersson007]

+1 from me to include the collection, could anyone from @ansible-collections/steering-committee or community conduct the second round of review?

[Andersson007]

Dear @ansible-collections/steering-committee , the collection is very small, could anyone please review it?

[oraNod]

I'll start the second review now.

[oraNod]

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
• 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 git 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 satisfy the concept of idempotency
  • 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 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)
• 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 (except cases when they were added in the very first release of the collection)
• FQCNs are used for extends_documentation_fragment:, unless you are referring to doc_fragments from ansible-core
• 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.11, - stable-2.12, - stable-2.13.
• 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
• 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
• all CI tests MUST run against every pull request
• all CI tests MUST run regularly (nightly, or at least once per week)
• sanity tests MUST run against a commit that releases the collection; if they don't pass, the collection won't be released

[oraNod]

+1 from me on inclusion

[oraNod]

@0xFelix I've done the second round of reviews and everything looks good to me. Thanks!

[Andersson007]

@ansible-collections/steering-committee could anyone please approve the collection? No review is needed, just an approval

[mariolenz]

@Andersson007 I've had a very quick look but it seems to be OK 👍

[Andersson007]

@mariolenz thanks! i'll open a topic ASAP

[Andersson007]

FYI https://forum.ansible.com/t/default-date-2024-04-30-collection-inclusion-include-kubevirt-core-in-the-ansible-community-package/5084

[felixfontein]

https://github.com/kubevirt/kubevirt.core/blob/main/docs/docsite/links.yml is copied directly from the collection template without any adjustments. Either adjust that file or delete it. This is a blocker for inclusion from my side, as including the collection with this links.yml will introduce a lot of broken data into the Ansible documentation.

Also I think the plugin/module documentation can be improved a bit by using more/better fitting Ansible markup, see https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_documenting.html#linking-within-module-documentation and the next two sections for details. Right now many things that should use V(), C(), E() etc. are just written as normal text, or use text quotes to indicate special values. (This can be improved over time, no need to rush this...)

[felixfontein]

@0xFelix ^

[0xFelix]

Yes, noticed it. Was not able to address this yet. Working on it.

[0xFelix]

kubevirt/kubevirt.core#95

@felixfontein Can you check this PR? It tries to improve the issues you mentioned.

[0xFelix]

@felixfontein There is a new release of kubevirt.core addressing the mentioned issues. Does it look good now?

[mariolenz]

@0xFelix We can't include this in Ansible 9 because of the dependency on kubernetes.core 3.1.0+, and there's a feature freeze for Ansible 10 at the moment. So I suggest to wait a few days before adding this.

Feel free to remind us if we haven't done this, say, end of the week...?

[felixfontein]

I created a PR: ansible-community/ansible-build-data#419

[mariolenz]

@Andersson007 @felixfontein @oraNod It looks like this collection is part of the Ansible community package since 10.2.0, so I've moved it to the resolved category. Feel free to undo this if you think I'm wrong.