Skip to content

@kmova kmova released this Jul 20, 2018 · 622 commits to master since this release

Getting Started

Using kubectl

kubectl apply -f
kubectl apply -f

Using Kubernetes Stable Helm charts

helm install  --namespace openebs --name openebs  -f stable/openebs
kubectl apply -f

Using OpenEBS Helm Charts (will be deprecated in the coming releases)

helm repo add openebs-charts
helm repo update
helm install openebs-charts/openebs

For more details refer to the documentation at:

New Capabilities / Enhancements

  • Integrate the Volume Snapshot capabilities with Kubernetes Snapshot controller
  • Enhance maya-apiserver to use CAS Templates for orchestrating new Storage Engines
  • Enhance mayactl to provide additional details about volumes such as - replica status and node details where replicas are running.
  • Enhance maya-apiserver to schedule Replica Pods on specific nodes using nodeSelector
  • Enhance provisioner and maya-apiserver to allow specifying cross AZ scheduling of Replica Pods.
  • Support for deploying OpenEBS via Kubernetes stable Helm Charts
  • openebs-operator.yaml is modified to run OpenEBS pods in its own namespace openebs
  • Enhance e2e tests to simulate chaos at different layers such as - CPU, RAM, Disk, Network, and Node

Major Issues Fixed

  • Fixed an issue where intermittent connectivity errors between controller and replica caused iSCSI initiator to mark the volume as read-only. openebs/gotgt#15
  • Fixed an issue where intermittent connectivity errors were causing the controller to silently drop the replicas and mark the Volumes as read-only. The replicas dropped in this way were not getting re-added to the Controller. openebs/jiva#45
  • Fixed an issue where volume would be marked as read-only if one of the three replicas returned an error to IO. openebs/jiva#56
  • Fixed an issue where replica fails to register back with the controller if the attempt to register occurred before the controller cleared the replica's previous state. openebs/jiva#56
  • Fixed an issue where a volume with a single replica would get stuck in the read-only state once the replica was restarted. openebs/jiva#45

Upgrade from older releases

Since 0.6 has made changes to the way controller and replica pods communicate with each other, the older volumes need to be upgraded with scheduled downtime for applications.


  • For OpenEBS volumes configured with more than 1 replica, at least more than half of the replicas should be online for the Volume to allow Read and Write. In the upcoming releases, with cStor data engine, Volumes can be allowed to Read/Write when there is at least one replica in the ready state.
  • This release contains a preview support for cloning an OpenEBS Volume from a snapshot. This feature only supports single replica for a cloned volume, which is intended to be used for temporarily spinning up a new application pod for recovering lost data from the previous snapshot.
  • While testing for different platforms, with a three-node/replica OpenEBS volume and shutting down one of the three nodes, there was an intermittent case where one of the 2 remaining replicas also had to be restarted.
  • The OpenEBS target (controller) pod depends on the Kubernetes node tolerations to reschedule the pod in the event of node failure. For this feature to work, TaintNodesByCondition alpha feature must be enabled in Kubernetes. In a scenario where OpenEBS target (controller) is not rescheduled or is back to running within 120 seconds, the volume gets into a read-only state and a manual intervention is required to make the volume as read-write.
  • The current version of OpenEBS volumes are not optimized for performance sensitive applications.
  • For a more comprehensive list of open issues uncovered through e2e, please refer open issues.

Additional details are available on Project Tracker Wiki.

Assets 2
You can’t perform that action at this time.