v2.4.0
Release v2.4.0
Release Date: 5th Sept., 2023
Summary
The version 2.4 introduces the standard storage cloning capability to the Mayastor storage engine by implementing Kubernetes volume restore functionality. Mayastor 2.4 also introduces a framework for generating and publishing events. The release enables provisioning persistent storage for Etcd and Loki containers with OpenEBS dynamic localpv hostpath provisioner. In addition, this release has DiskPool CRD updates and fixes related to snapshots, upgrade, availability and supportability.
Features
Volume Restore from Snapshots
A snapshot of a Mayastor volume is a point-in-time read-only copy of the volume. Snapshot support was added in the previous release (v2.3). The current release adds support to create a new volume from an existing snapshot. In Kubernetes semantics, this is the equivalent of restoring a volume from a snapshot by specifying the source of the volume as a snapshot in the PVC manifest.
It is important to note that this feature is being released with the below limitation:
The current release supports creating a restore volume with only one replica. Support for restoring to multi-replica volumes will be added in the future.
It is also important to note that the StorageClass specified in the PVC for a restore volume, must have ‘thin' parameter set to 'true’.
Please refer the documentation for more details.
Eventing
Eventing is an important part of monitoring of any system. Mayastor 2.4 introduces an eventing framework which enables important events to be generated from the core components. The generated events are published onto a NATS message bus. As a part of this framework, we have introduced NATS into the system along-with a statistics module which subscribes for the events on the NATS, aggregates them and exports useful metrics in the Prometheus format.
In the current release, events are generated for creation and deletion of Mayastor pools and volumes.
Please refer the documentation for more details. Eventing can be disabled as per the steps here.
OpenEBS LocalPV Storage for Etcd and Loki
Etcd and Loki are installed as a part of the regular deployment of Mayastor. This is because, Mayastor uses etcd to persist the configuration and state settings, and Loki for storing the system logs. Both etcd and Loki are installed as Kubernetes StatefulSets and the storage for them is provisioned using either the cluster default storage class or static host path persistent volumes. There are limitations with this configuration:
A cluster default StorageClass exists only in managed Kubernetes environments (eg. Google Kubernetes Engine). The on-premise and self-managed clusters may not have a default StorageClass.
In the static host path approach, manual intervention is needed to pre-create persistent volumes on all nodes where the stateful pods of etcd and Loki could be possibly scheduled.
Mayastor 2.4 addresses this limitation using the OpenEBS dynamic localpv provisioner for creation of hostpath PVs. This provisioner is installed as a part of Mayastor 2.4 helm installation and custom storage classes are created, one each for Etcd and Loki. Using these classes, PVs are created dynamically for each statefulset pod of Etcd and Loki. The dynamic provisioning also enables easy scaling up of etcd and Loki replicas.
DiskPool CRD Update
In release 2.4, Mayastor DiskPool CustomResource version has been updated to v1beta1 (previously v1alpha1), where the “state“ field is deprecated and replaced by “cr_state“ and “pool_status“.
Related issues encountered when upgrading to version 2.4 can be resolved by following the steps documented here.
Snapshot Fixes
Fix/SPDK API to set attributes for snapshot by mtzaurus · Pull Request #1471 · openebs/mayastor
Handle discarded snapshots by tiagolobocastro · Pull Request #660 · openebs/mayastor-control-plane
Availability Fixes
Adding Command Retry Delay option feat(nvmf): adding support for configuring target CRD by dsavitskiy · Pull Request #1491 · openebs/mayastor
Supportability Fixes
Upgrade Enhancements and Fixes
refactor(upgrade-job): change dry-run helm upgrade implementation by niladrih · Pull Request #328 · openebs/mayastor-extensions
Testing
Mayastor is subject to extensive unit, component and system-level testing throughout the development and release cycle. Resources for system-level (E2E) testing are currently provided by DataCore Software.
At this time, personnel and hardware resource limitations constrain testing by the maintainers to linux builds on x86. This reflects the primary use-case which the maintainers are currently targeting with the OpenEBS Mayastor project. Therefore, the use of Mayastor with other operating systems and/or architectures, if even possible, should be considered serendipitous and wholly experimental.
This release has been subject to End-to-End testing under Ubuntu 20.04.5_LTS (kernel: ubuntu-5.15.0-50-generic)
- Tested k8s versions
- 1.23.7
- 1.24.14
- 1.25.10
Known behavioural limitations
-
As with the previous versions, the Mayastor IO engine makes full utilisation of the allocated CPU cores regardless of I/O load. This is the poller operating at full speed, waiting for I/O.
-
As with the previous versions, a Mayastor DiskPool is limited to a single block device and cannot span across more than one block device.
Known issues
-
Mayastor does not support capacity expansion for volumes as of v2.4.0.
-
Mayastor does not support capacity expansion of DiskPools as of v2.4.0.
-
Under heavy IO and constant scaling up-down of volume replicas, the io-engine pod has been observed to restart occassionally.
Getting Started
Mayastor user documentation, including a quick deployment guide, can be found here
Upgrade
Upgrades from versions of Mayastor prior to v1.0.0 are not supported. Any release earlier than v1.0.0 should be removed prior to installing this version.
Users get the support for upgrading the software from version 2.0.0 | 2.0.1 | 2.1.0 | v2.2.0 | v2.3.0 to v2.4.0
Support For Migration From Legacy Versions
Mayastor versions 1.0.5 and prior, are being considered as legacy versions. Due to several breaking changes in the 2.0 codebase of the software, it is not possible to support seamless upgrades from the legacy versions to the current version. Mayastor 2.2 provides a documented migration path for users to move their legacy installations to the latest version.
Please refer the documentation for more information.
Support
If you are having issues during installation, configuration or upgrade, you can contact us via:
- OpenEBS on Kubernetes Slack community
- Already signed up? Head to our discussions at #openebs
- Raising an issue
"Unsupported" Architectures and Operating Systems (inc. ARM, Raspberry Pi, MacOS)
As described in the section on software testing above, the maintainers build and test Mayastor only on linux, on x86-64. The use of Mayastor in other environments is therefore not necessarily possible, at least without modification. Where possible, this is currently largely coincidental - it is not "fully" tested and therefore this should be considered an entirely experimental use-case.
The maintainers will be pleased to receive contributions in this area, with the following understanding:
- Such PR's will be reviewed for correctness, good practice, licensing compliance and general quality
- PR's will be accepted on the basis that testing by the maintainers is restricted to demonstrating no negative affect on the stability of x86-64 builds
- The maintainers will not perform acceptance testing or "positive release" of such functionality on any other OS or architecture, which is in accordance with their designation of these environments as experimental use cases at this time.
- The maintainers will not provide build artifacts or container images for these environments