v2.3.0
Release v2.3.0
Release Date: 22nd July, 2023
Summary
Mayastor 2.3 introduces the industry standard storage snapshotting capabilities in the Mayastor storage engine. Kubernetes application users and administrators will now be able to create, list and delete instantaneous snapshots of Mayastor Persistent Volumes based on standard CSI specifications. Mayastor 2.3 also provides APIs to view the history of volume and replica rebuilds. In addition, this release has fixes related to HA, thin provisioning, rebuilding, stability and node drain operations.
Features
Volume Snapshots
A snapshot of a Mayastor volume is a point-in-time read-only copy of the volume. In this release, Mayastor provides support for industry standard copy-on-write (COW) snapshots, which is a popular methodology for taking snapshots by keeping track of only those blocks that have changed. Mayastor supports snapshots in a Kubernetes-native way. A snapshot controller and side-car are deployed alongside the CSI driver and the Kubernetes CRDs namely VolumeSnapshotClass, VolumeSnapshotContent and VolumeSnapshot are also deployed during the installation. By creating a custom resource of kind VolumeSnapshot, a user can easily take a snapshot of the Mayastor volume.
Please refer the documentation for more details.
It is important to note that this feature is being released with the below limitations:
The current release supports snapshots only for single-replica volumes. Support for snapshotting multi-replica volumes will be provided in the future.
The current release does not support creation of a clone or a new volume from an existing snapshot.
Rebuild History
The Mayastor volume replicas are usually distributed across storage nodes to ensure availability and guard against failures. Whenever a replica becomes inaccessible, the volume target (Mayastor nexus) marks the replica as faulted and a rebuilding process is spawned to recover the faulted replica. If the replica is rebuilt from scratch, it is known as a full rebuild process. If a replica is rebuilt from an intermediate point using a recovery log, it Is known as a partial rebuild process. Mayastor 2.3 provides API to view the history of rebuilds of all replicas attached to the current volume target (nexus). Users can invoke the Mayastor kubectl plugin with a get rebuild-history option to retrieve the rebuild records for a specific volume target.
Please refer the documentation for more details.
HA and Drain Fixes
Thin-Provisioning Fixes
Stability Fixes
Add concurrency limiter for create volume operations upto 10.
Volume Snapshot Commitment by tiagolobocastro · Pull Request #619 · openebs/mayastor-control-plane
chore(core): errno mapping for core errors by mtzaurus · Pull Request #1418 · openebs/mayastor
fix(nvmx): fixing async qpair connection bugs by dsavitskiy · Pull Request #1405 · openebs/mayastor
Supportability Fixes
Upgrade Fixes
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 even when there is less or no I/O load. This is the poller operating at full speed, waiting for I/O.
-
As with the previous versions, a Mayastor disk pool is limited to a single block device and cannot span across more than one block device.
Known issues
-
Mayastor does not support creation of clones from snapshots as of v2.3.0. This is a work-in-progress feature.
-
Mayastor does not support capacity expansion for volumes v2.3.0.
-
Mayastor does not support capacity expansion of disk pools as of v2.3.0.
-
Under heavy IO and constant scaling up-down of volume replicas, the io-engine pod has been observed to restart occasionally.
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 to v2.3.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