[Incubation] OpenEBS Incubation Application #1537
Labels
Comments
|
Edit [03/13/2025]: Project presentation to TAG Storage has been completed on 12th Mar 2025. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Review Project Moving Level Evaluation
OpenEBS Incubation Application
v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.
Project Repo(s): https://github.com/openebs/openebs
Project Site: https://openebs.io
Sub-Projects: Local PV Hostpath, Local PV LVM, Local PV ZFS, Local PV Rawfile (Experimental), Mayastor
Communication: OpenEBS channel in Kubernetes Slack workspace
Project points of contacts:
OpenEBS email: [email protected]
Incubation Criteria Summary for OpenEBS
Application Level Assertion
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.
OpenEBS team presented to Storage TAG committee on 12th Mar 2025 as part of Incubation application. Awaiting insights.
OpenEBS team had earlier made a presentation to the Storage TAG committee on 24th July 2024 as part of Sandbox application. The recording is available at https://www.youtube.com/watch?v=V_KG9bMrb38.
Below suggestions from TAG have been incorporated into the project:
The team has reached out to Storage TAG for a new incubation-related review. Per the advice from a TAG member, this is planned as part of application evaluation.
TAG provides insight/recommendation of the project in the context of the landscape
All project metadata and resources are vendor-neutral.
Yes, OpenEBS is designed to be vendor-neutral, aligning with the principles of the Cloud Native Computing Foundation (CNCF). CNCF's vendor neutrality guidelines mandate that projects ensure that no single company is favored over others, in areas like communication, hosting, architectural decisions, and governance.
Vendor neutral communication:
Hosting:
Architectural decisions:
Governance:
Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
Sandbox onboarding requirements have been completed with cncf/sandbox#299.
Due Diligence Review.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies 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.
Navigate to the OpenEBS Docs and use the left panel to navigate to the appropriate sub-page.
Installation docs: https://openebs.io/docs/quickstart-guide/installation
End-user docs: https://openebs.io/docs/
Solution guides:
Since we do not expose/support libraries, we’re not highlighting any code samples here.
Governance and Maintainers
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
Clear and discoverable project governance documentation.
The Governance Doc is located in the community repo and can be discovered from all OpenEBS repositories via signpost links.
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.
As OpenEBS has been maturing, the Maintainers have been iterating over the project governance as deemed appropriate. The changes to the governance can be tracked in the GOVERNANCE.md commit history.
Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.
Governance clearly documents vendor-neutrality of project direction.
Document how the project makes decisions on leadership, 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 a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.
Required
Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.
This information is present in the MAINTAINERS.md
A number of active maintainers which is appropriate to the size and scope of the project.
OpenEBS currently has 5 Maintainers. We encourage contributors to climb up the ladder to become Maintainers.
Code and Doc ownership in Github and elsewhere matches documented governance roles.
All the repositories have CODEOWNERS files.
Document adoption of the CNCF Code of Conduct
https://github.com/openebs/community/blob/HEAD/CODE_OF_CONDUCT.md
CNCF Code of Conduct is cross-linked from other governance documents.
Documented in our Code of Conduct.
All subprojects, if any, are listed.
OpenEBS is a unified umbrella project that provides options for local and replicated PVs. Presently, there are 4 Local PV engines (Hostpath, ZFS, LVM, Rawfile) and 1 Replicated PV engine (Mayastor). Each engine can be considered as a sub-project, as listed below:
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 GOVERNANCE.md lists down the roles and responsibilities for the various types of contributors. It also explains the journey of a contributor to become a maintainer.
Required
Clearly defined and discoverable process to submit issues or changes.
The CONTRIBUTING.md details how to report product, documentation or security issues, and how to contribute to code, documentation or support.
Project must have, and document, at least one public communications channel for users and/or contributors.
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.
OpenEBS Slack Channels:
Maintainer’s group: [email protected]
Up-to-date public meeting schedulers and/or integration with CNCF calendar.
The OpenEBS Community Meeting is scheduled for the last Thursday of the month at 14:00 UTC. The event is listed on the CNCF calendar: https://www.cncf.io/calendar.
Documentation of how to contribute, with increasing detail as the project matures.
This is documented at a high level in the contribution guide.
Each sub-project has its own contribution docs as well:
Demonstrate contributor activity and recruitment.
Contributor growth rate and activity can be seen through LFX Insights
Engineering Principles
Suggested
Roadmap change process is documented.
The roadmap change process is documented at https://github.com/openebs/community/blob/HEAD/ROADMAP.md#roadmap-change-process
History of regular, quality releases.
This information is available on the github releases.
Each sub-project exposes their own github releases as well:
Required
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 can also be satisfied by completing a General Technical Review.
The OpenEBS vision documents the goals and objectives of OpenEBS, and attempts to illustrate the project’s differentiation in the Cloud Native landscape.
Document what the project does, and why it does it - including viable cloud native use cases. This can also be satisfied by completing a General Technical Review.
The OpenEBS vision attempts to establish the purpose of OpenEBS as a solution for enterprises to efficiently manage their stateful workloads in a cloud native ecosystem. The document also lists the key features of OpenEBS and the viable cloud native use-cases.
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
The public ROADMAP.md lists the near-term and long-term roadmap for the project, with potential timelines for features and enhancements.
The public GitHub Roadmap Project is used to plan and track with focus on the execution of the roadmap items, issues and bugs, mapped against the releases.
Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This can also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.
Overview of project architecture for the project and sub-projects:
Location for the design documents: https://github.com/openebs/openebs/tree/HEAD/designs
Document the project's release process.
The release processes for the project and sub-projects:
Security
Note: this section may be augmented by a joint-assessment performed by TAG Security.
Suggested
N/A
Required
Clearly defined and discoverable process to report security issues.
The process is documented at SECURITY.md.
Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
OpenEBS code is hosted in GitHub and uses GitHub teams for controlling access to the various repositories. Maintainers have enabled 2FA at the org level, which enforces Two Factor Authentication for all the org members. The org membership is periodically reviewed and kept up-to-date by the maintainers.
Document assignment of security response roles and how reports are handled.
This is documented in the SECURITY.md.
Document Security Self-Assessment.
Please find the security self-assessment document here.
Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.
OpenEBS and each of the sub-projects have achieved OpenSSF Best Practices Passing Badge and it is displayed on the project and sub-projects README, as listed below:
Ecosystem
Suggested
N/A
Required
Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
The ADOPTERS.md contains an alphabetical list of OpenEBS adopters, both organizations and individuals. For each adopter, a success story link details the use-case, applications and the nature of deployment (dev/trialing/production), provided by the adopters themselves.
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 has received confirmation from THREE adopters, waiting for responses from others. Will soon be providing the TOC with a list of adopters for verification.
02/25/2025: Have submitted Adopter Interview Form with details of 3 adopters. Awaiting confirmation from more.
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.
OpenEBS integrations with other CNCF and non-CNCF projects are documented at https://github.com/openebs/community/blob/HEAD/README.md#integrations-with-other-projects.
Additional Information
The text was updated successfully, but these errors were encountered: