WIP: KubeVirt Graduation Application

[aburdenthehand]

This is the CNCF graduation template to ensure that we have all requirements complete or tracked.

Project Repo(s): https://github.com/kubevirt/
Project Site: https://kubevirt.io
Sub-Projects: https://github.com/orgs/kubevirt/repositories?type=all
Communication: https://kubernetes.slack.com/messages/kubevirt-dev & https://kubernetes.slack.com/messages/virtualization

Project points of contacts:
Andrew Burden, [email protected]
Fabian Deutsch, [email protected]
Ryan Hallisey, [email protected]

Graduation Criteria Summary for KubeVirt

Application Level Assertion

• This project is currently Incubating, accepted on YYYYMMDD, and applying to Graduate.

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

Application Process Principles

Suggested

N/A

Required

• Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review. #310
  • This was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.

• TAG provides insight/recommendation of the project in the context of the landscape

• All project metadata and resources are vendor-neutral.

• Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.
  • Met during Project's application on DD-MMM-YYYY.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

Our first major updates to our governance doc in three years are adding clarity on our updated SIG governance, and adding the same for Subprojects and Working Groups:

• community, wg, template: create wg templates #301
• community, wg, arch: add wg, sig subprojects and charter for S390x and ARM #298

Required

• Clear and discoverable project governance documentation.

Our governance doc and our membership policy are in the root of our community repo. These are also linked to from the README, and in the user guide contributing page.

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

(Waiting on #301, #298, and #306 to merge)
Our governance doc and membership policy explain the domains of the maintainers, SIGs, WGs, and Subprojects, as well as our contributor ladder to grow into a reviewer, approver, SIG/WG/Subproject Chair/Lead, and maintainer role.
SIG meetings are captured in the charters for each SIG and in our sigs.yaml file in our community repo, linked to from the governance doc.

• Governance clearly documents vendor-neutrality of project direction.

• Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation. #315

• A number of active maintainers which is appropriate to the size and scope of the project.

Our maintainer file shows 8 maintainers, all of whom have contributed to the project in the last month (according to devstats as of time of writing).

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status). #311

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

• Project maintainers from at least 2 organizations that demonstrates survivability.

Our maintainer file shows maintainers from Google, NVIDIA, Red Hat, and SUSE

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

• Document agreement that project will adopt CNCF Code of Conduct.

• CNCF Code of Conduct is cross-linked from other governance documents.

• All subprojects, if any, are listed.

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Contributor ladder with multiple roles for contributors.

Our membership policy demonstrates the different roles and requirements and expectations of these roles.

Required

• Clearly defined and discoverable process to submit issues or changes.

Our kubevirt/kubevirt repo has a contributing page that is linked to from the readme and details our workflow or raising issues and PRs (including finding good-first-issues) and questions on our mailing list. It also covers testing, DCO, the PR merge/review process, and our membership policy.

We also have a contributing guide as part of our user guide which links out to these resources, including the CNCF 'Start Contributing to Open Source' page, and helps guide new contributors through the project.

• Project must have, and document, at least one public communications channel for users and/or contributors.

We have a mailing list, and two slack channels: kubevirt-dev and virtualization.
These are listed in out user guide contributing guide, our kubevirt/kubevirt contributing guide, and the kubevirt/kubevirt and kubevirt/community readmes.

• List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

Mailing list: [email protected]
Developer-oriented slack channel: https://kubernetes.slack.com/messages/kubevirt-dev
User-oriented slack channel: https://kubernetes.slack.com/messages/virtualization
Twitter: https://twitter.com/kubevirt
Youtube: https://www.youtube.com/channel/UC2FH36TbZizw25pVT1P3C3g/videos

Non-public
Maintainer list: [email protected]; reporting CoC violations, communication between the maintainers and the CNCF
Security list: [email protected]; reporting security vulnerabilities privately

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

Our calendar is up to date and linked to from our website, user-guide, community repo and relevant SIG charters.

• Documentation of how to contribute, with increasing detail as the project matures.

Our kubevirt/kubevirt repo has a contributing page and a getting started page, the latter of which is focussed specifically for contributing developers.

We also have a contributing guide as part of our user guide.

• Demonstrate contributor activity and recruitment.

Engineering Principles

• Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This requirement may also be satisfied by completing a General Technical Review. #340
• A General Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.

• Document what the project does, and why it does it - including viable cloud native use cases. This requirement may also be satisfied by completing a General Technical Review.
  • A General Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism. #339

• Roadmap change process is documented.

We have a design proposal process, the template of which is linked to from our kubevirt/kubevirt contributing page.

We also have an upcoming changes document that shows our 'pre-release notes': the release notes for our next release. It is updated daily as development progresses.

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This requirement may also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.
  • A General Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.

• Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:

  • Release expectations (scheduled or based on feature implementation)
  • Tagging as stable, unstable, and security related releases
  • Information on branch and tag strategies
  • Branch and platform support and length of support
  • Artifacts included in the release.
  • Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.

1. Release expectations: we have a public schedule in our sig-release repo. We check in with the current release schedule every week during our community meeting.
2. Tagging: TODO
3. Information on branch and tag strategies: These strategies are details in our release document.
4. Branch and platform support: We have a release document that details our versioning and support. We also maintain a support matrix which is linked to in our release tag notes, as well as our kubevirt and community readmes and our release notes.
5. Artifacts included in release: TODO

• History of regular, quality releases.

From 2017 to 2022, KubeVirt would release on a monthly cadence, with an RC approximately 10 days prior to release to ensure a tested, quality release. Since October 2022, the project moved to a tri-annual release, following in lock-step with the Kubernetes release; with this change we now have a three-week period of testing, with alpha, beta, and at least one RC prior to the release.

This history can be found on our releases page of kubevirt/kubevirt: https://github.com/kubevirt/kubevirt/releases
Our release schedules can be found on our sig-release repo: https://github.com/kubevirt/sig-release/tree/main/releases
Our release notes can be found in our user guide (and in the release tag): https://kubevirt.io/user-guide/release_notes/

Security

Note: this section may be augmented by a joint-assessment performed by TAG Security.

Suggested

• [] Achieving OpenSSF Best Practices silver or gold badge.

Required

• Clearly defined and discoverable process to report security issues.

Our security policy is included in our kubevirt, containerized-data-importer, user-guide, and sig-release repos. It details how to privately report a vulnerability and the required information, an alternate method for privately reporting (for when the email address cannot be used, which we experienced in 2023), how the security notices are delivered, and the involved vendor security teams

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.) #337

• Document assignment of security response roles and how reports are handled. #336

• Document Security Self-Assessment. #335

• Third Party Security Review.

  • Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs.

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

The project has a passing badge since 2021. It was comprehensively updated on 2024-04-12 15:48:53 UTC. The passing badge is visible on our kubevirt/kubevirt readme.

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

Our adopter list is visible in our kubevirt/kubevirt repo and contains 32 adopters: https://github.com/kubevirt/kubevirt/blob/main/ADOPTERS.md

• Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)

The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

• TOC verification of adopters.

Refer to the Adoption portion of this document.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects. #338

Adoption

Adopter 1 - $COMPANY/$INDUSTRY

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.
MONTH YEAR

Adopter 2 - $COMPANY/$INDUSTRY

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.
MONTH YEAR

Adopter 3 - $COMPANY/$INDUSTRY

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.
MONTH YEAR