OpenEBS control plane components like provisioners and operators were hosted in this repository.
As the OpenEBS community started to add new engines, the engine specific control plane components have been moved to their respective repositories.
- cStor operators and CSI driver have moved to openebs/cstor-operators and openebs/cstor-csi respectively.
- Jiva operator and CSI driver have moved to openebs/jiva-operator
- Local PV Hostpath and Device provisioner has been moved to openebs/dynamic-localpv-provisioner
- Jiva and cStor prometheus metrics exporter been moved to openebs/m-exporter
mayactlfor displaying status of Jiva and cStor volumes is merged into openebs/openebsctl
This repository mainly contains code required for running the legacy cStor and Jiva pools and volumes like:
m-apiserver- used for provisoining the legacy cStor and Jiva pools and volumes.mayactl- packaged along withm-apiserverfor fetching the legacy cStor and Jiva volume status.
admission-server- used for validating Jiva and cStor pool and volume requests.m-upgrade- used for upgrading the legacy Jiva volumes, cStor pools and volumes.cstor-pool-mgmtandcstor-volume-mgmt- used for managing the legacy cStor pool and volumes.
With OpenEBS 3.0, all of the above legacy components are deprecated and users are requested to migrate towards using:
- CStor CSI Driver
- Jiva CSI Driver
The steps to migrate are provided here: https://github.com/openebs/upgrade.
v2.12.x is the last active branch on this repository, that will be used to mainly resolve any security vulnerability or kubernetes compatibility issues found on production setups using the legacy provisioners. New features will be developed only cStor and Jiva CSI drivers.
Please refer to our documentation at OpenEBS Documentation.
Prior to creating a release tag on this repository on v2.12.x branch with the required fixes, ensure that:
- the dependent data engine repositories and provisioner are tagged.
- update the versionDetails.go to include the supported upgrade path.
Once the code is merged, use the following sequence to release a new version for the legacy components:
- New release tag on v2.12.x branch of openebs/linux-utils
- (If required) New release tag on v0.6.x branch of openebs/ndm
- New release tag on v2.12.x branch of openebs/cstor and openebs/libcstor
- New release tag on v2.12.x branch of openebs/jiva
- New release tag on v2.12.x branch of openebs/openebs-k8s-provisioner
- New release tag on v2.12.x branch of openebs/m-exporter
- New release tag on v2.12.x branch of openebs/maya
- New release tag on v2.12.x branch of openebs/velero-plugin
Note: The github release workflows are setup to push the tag to the dependent repositories. In the above case, if a release tag is created on v2.12.x branch of linux-utils, then it will trigger the releases down to velero-plugin repo.
Once the tags are generated update the helm charts and YAMLs at:
- https://github.com/openebs/charts/tree/2.x/charts/openebs/templates/legacy
- https://github.com/openebs/charts/tree/main/charts/openebs/templates/legacy
- https://github.com/openebs/charts/blob/gh-pages/legacy-openebs-operator.yaml
We are looking at further refactoring this repository by moving the common packages from this repository into a new common repository. If you are interested in helping with the refactoring efforts, please reach out to the OpenEBS Community.
For details on setting up the development environment and fixing the code, head over to the CONTRIBUTING.md.
OpenEBS welcomes your feedback and contributions in any form possible.
- Join OpenEBS community on Kubernetes Slack
- Already signed up? Head to our discussions at:
