OpenEBS was accepted as a Sandbox project in 2019, then moved to archive in Feb 2024. For background on why, see OpenEBS - why we were archived. The project team and sponsoring company have made changes in order to ensure the long term sustainability of OpenEBS. We are asking to unarchive the project, and are challenging ourselves to move forward in the CNCF maturity process.
OpenEBS provides enterprise grade block storage for Kubernetes, enabling persistent resilient cloud native storage (storage is managed-from and contained-within a Kubernetes cluster). OpenEBS is popular, with >25,000 new clusters installed every month.
This is a re-application to Sandbox. Project was archived Feb 2024 after TOC vote on 1051. š¢ The team has listened to TOC feedback, has made changes š , and is now seeking readmission to Sandbox.
Changes include:
Archived older storage engines and consolidated engines from 11 to 4 (75 repos to 38), these are the actively maintained repos that will be further developed in the future.
Reworked documentation
Reworked all governance docs, and centralized to umbrella Community repo
Rewrote project docs including Vision.md, Governance.md, Contributing.md
Instituted processes inside the project, so people abide by the project docs
Engaged with Linux Foundation brand counsel (DanielC) to bring DataCoreās commercial offering into compliance
Project members attended KubeCon Paris, in order to engage with the community on how best to proceed reapplying for sandbox in the most efficient manager possible - weāve been working with the CNCF Projects team to help us meet the requirements. (ChrisA and JorgeC)
Educated parent company DataCoreās staff on open source and CNCF policies and procedures
Assigned a CNCF liaison (Ed Robinson), who reports to DataCore CEO to represent the project and take guidance from the TOC
We hope to gain admission to Sandbox soon, then work with CNCF towards incubation, then graduation.
Org repo URL (provide if all repos under the org are in scope of the application)
The new OpenEBS project consists of 5 Storage Engines. The strategy is to eventually unify all 5 into 1 platform. There are sub repos & dependencies, 1 sub project & 1 critical external fork dependency. We took advice from TOC, and advised community, then deprecated, then moved tech-debt of 44 legacy repos to openebs-archive org based on guidance from @caniszczyk and @castrojo. - Our new repo structure is listed below, with engines listed in order of User Adoption:
The new project roadmap & strategy is to Unify 5 Storage Engines into 1 single Storage platform, covering Local PV, Replicated PV, 3 Backend Storage Mgmt stacks and 7 Tier-1 Cloud Providers. This is a major project change compared to the old roadmap, which did not provide any attention, love or focus on the 4 Local PV engines. This lack of focus on our behalf created a stale & disappointed community with low contribs. - We acknowledge that this was wrong and our new Roadmap + VISION doc now defines a specific commitment to the very large Local PV community (1.7Million users).
In support of the new Roadmap, we defined a VISION doc as part of our new GOVERNANCE structure that supports the roadmap and helps guide us, our devs contribs and the community
[X] If the project is accepted, I agree the project will follow the CNCF IP Policy
Trademark and accounts
[X] If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF
Why CNCF?
OpenEBS was accepted as a Sandbox project in 2019, then moved to archive in Feb 2024.
We have re-examined why we want to continue to contribute to CNCF. Here is why:
We believe cloud native computing is a generational change in how people build, deploy and use software
No one should own the futureās platform, it needs to be open source for the world to fully embrace it, and to nurture innovation
We see CNCF as an organization able to protect, guide and nurture the Kubernetes open source platform
The part we can contribute is block storage. This is ārocket scienceā, and one of the last last areas of technology to be open sourced, because it takes a large team, months of innovation + years of testing.
OpenEBS adds >25,000 clusters to our install base every month, it meets an important requirement for Kubernetes users who choose to manage storage from within their cluster
Our project team is proud of our progress, and being able to work with cloud-native adopters, together we are inventing and protecting the future.
Benefit to the Landscape
āNo one thinks about their storage until it stops workingā
Since the OpenEBS project started, we have innovated in a number of areas: we were the first to truly develop container native storage, the first to bring replicated storage with NVMe driver to Kubernetes
OpenEBS meets an important requirement for the many many Kubernetes users who choose to manage storage from within their cluster
The four overarching benefits to the landscape are:
OpenEBS strengthens the K8s landscape with Enterprise Grade Data Management capabilities
We provide the ability to manage and provision storage from within a Kubernetes cluster, with no reliance on external services
Data resilience and data protection
Simplicity - our goal is to continually make the product simpler, with sensible defaults and āit just worksā
Cloud Native 'Fit'
OpenEBS is cloud native storage. Designed from the ground for Kubernetes. Every one of our maintainers, contributors and users are Kubernetes users.
Every K8s user should have the choice to use internal or external storage. Without a cloud native, enterprise storage solution like OpenEBS, people donāt have the choice, and have to rely on external non-cloud-native storage.
DataCore has a commercial offering complementing OpenEBS.
After consultation with Linux Foundation (DanielC brand counsel), the commercial offering will NOT use the name OpenEBS PRO. The name is being decided, it will comply with LF trademark usage guidelines.
OpenEBS and DataCoreās commercial offering have clearly defined separate scopes (see VISION.md in community docs).
OpenEBS provides a core set of storage drivers, resilience, availability and fault tolerance
DataCore commercial offering is targeting enterprises, with 24x7 production support, enterprise integrations, platform optimizations (eg: DataCore is providing an optimized product for hosted Kubernetes platforms)
For organization:
DataCoreās development uses a different development environment
DataCore employees are assigned to work in either the open source project or commercial offering
Open source assignment or commercial assignment is clearly delineated and not mixed together
Project presentations
Prior to project-archiving, OpenEBS has participated with TAG Storage (the presentations may have been archived). There have been no presentations post-project-archiving.
Project champions
Jorge Castro
Chris Aniszczyk
Emily Fox
Nick Connolly
Alex Chircop
Additional information
OpenEBS was accepted to Sandbox five years ago. Since then the project has become the most widely adopted Kubernetes storage solution.
We have accepted and adopted changes recommended by the TOC in February 2024.
OpenEBS is an important project.
People rely on OpenEBS as a foundation for their Kubernetes infrastructure: We have a lot of production installations, including Microsoft who use OpenEBS in Azure Container services; CIVO who use OpenEBS as the basis for their hosted storage; Flipboard, Indiaās largest eCommerce service who rely on OpenEBS for their storage.
While OpenEBS is in Archive, our users are uncertain of the projectās future, and the future of their own software that depends on OpenEBS.
We request TOC considers a promotion to Sandbox as soon as possible, and we will work with CNCF to develop and execute a plan to move the project to incubation status immediately afterwards.
edrob999
commented
1 week ago
Application contact emails
ed.robinson@gmail.com, brace.dave@gmail.com
Also see OpenEBS project leadership Maintainers team
Project Summary
Cloud native storage
Project Description
OpenEBS was accepted as a Sandbox project in 2019, then moved to archive in Feb 2024. For background on why, see OpenEBS - why we were archived. The project team and sponsoring company have made changes in order to ensure the long term sustainability of OpenEBS. We are asking to unarchive the project, and are challenging ourselves to move forward in the CNCF maturity process.
OpenEBS provides enterprise grade block storage for Kubernetes, enabling persistent resilient cloud native storage (storage is managed-from and contained-within a Kubernetes cluster). OpenEBS is popular, with >25,000 new clusters installed every month. This is a re-application to Sandbox. Project was archived Feb 2024 after TOC vote on 1051. š¢ The team has listened to TOC feedback, has made changes š , and is now seeking readmission to Sandbox. Changes include:
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/openebs
Project repo URL in scope of application
https://github.com/openebs/mayastor
Additional repos in scope of the application
The new OpenEBS project consists of 5 Storage Engines. The strategy is to eventually unify all 5 into 1 platform. There are sub repos & dependencies, 1 sub project & 1 critical external fork dependency. We took advice from TOC, and advised community, then deprecated, then moved tech-debt of 44 legacy repos to openebs-archive org based on guidance from @caniszczyk and @castrojo. - Our new repo structure is listed below, with engines listed in order of User Adoption:
Website URL
https://openebs.io
Roadmap
https://github.com/openebs/openebs/blob/main/ROADMAP.md
Roadmap context
The new project roadmap & strategy is to Unify 5 Storage Engines into 1 single Storage platform, covering Local PV, Replicated PV, 3 Backend Storage Mgmt stacks and 7 Tier-1 Cloud Providers. This is a major project change compared to the old roadmap, which did not provide any attention, love or focus on the 4 Local PV engines. This lack of focus on our behalf created a stale & disappointed community with low contribs. - We acknowledge that this was wrong and our new Roadmap + VISION doc now defines a specific commitment to the very large Local PV community (1.7Million users).
In support of the new Roadmap, we defined a VISION doc as part of our new GOVERNANCE structure that supports the roadmap and helps guide us, our devs contribs and the community
Contributing Guide
https://github.com/openebs/community/blob/develop/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/openebs/community/blob/develop/CODE_OF_CONDUCT.md
Adopters
https://github.com/openebs/community/blob/develop/ADOPTERS.md
Contributing or Sponsoring Org
https://www.datacore.com/
Maintainers file
https://github.com/openebs/community/blob/develop/MAINTAINERS
IP Policy
Trademark and accounts
Why CNCF?
OpenEBS was accepted as a Sandbox project in 2019, then moved to archive in Feb 2024.
We have re-examined why we want to continue to contribute to CNCF. Here is why:
Benefit to the Landscape
āNo one thinks about their storage until it stops workingā
The four overarching benefits to the landscape are:
Cloud Native 'Fit'
OpenEBS is cloud native storage. Designed from the ground for Kubernetes. Every one of our maintainers, contributors and users are Kubernetes users.
Every K8s user should have the choice to use internal or external storage. Without a cloud native, enterprise storage solution like OpenEBS, people donāt have the choice, and have to rely on external non-cloud-native storage.
Cloud Native 'Integration'
Kubernetes Containerd KubeVirt Kubernetes Etcd NATS HELM gRPC Jaegar OpenTelemetry Prometheus Open Telemetry
Cloud Native Overlap
Longhorn (storage) CubeFS (storage) Rook/Ceph (storage)
Similar projects
Longhorn (storage) CubeFS (storage) Rook/Ceph (storage)
Landscape
Cloud Native Storage
Business Product or Service to Project separation
DataCore has a commercial offering complementing OpenEBS. After consultation with Linux Foundation (DanielC brand counsel), the commercial offering will NOT use the name OpenEBS PRO. The name is being decided, it will comply with LF trademark usage guidelines.
OpenEBS and DataCoreās commercial offering have clearly defined separate scopes (see VISION.md in community docs).
For organization:
Project presentations
Prior to project-archiving, OpenEBS has participated with TAG Storage (the presentations may have been archived). There have been no presentations post-project-archiving.
Project champions
Jorge Castro Chris Aniszczyk Emily Fox Nick Connolly Alex Chircop
Additional information
OpenEBS was accepted to Sandbox five years ago. Since then the project has become the most widely adopted Kubernetes storage solution.
We have accepted and adopted changes recommended by the TOC in February 2024.
OpenEBS is an important project. People rely on OpenEBS as a foundation for their Kubernetes infrastructure: We have a lot of production installations, including Microsoft who use OpenEBS in Azure Container services; CIVO who use OpenEBS as the basis for their hosted storage; Flipboard, Indiaās largest eCommerce service who rely on OpenEBS for their storage.
While OpenEBS is in Archive, our users are uncertain of the projectās future, and the future of their own software that depends on OpenEBS.
We request TOC considers a promotion to Sandbox as soon as possible, and we will work with CNCF to develop and execute a plan to move the project to incubation status immediately afterwards.