Releases: openebs/mayastor
v1.0.5
Release v1.0.5
Release Date: 13th December 2022
Summary
This patch release contains important fixes and supportability enhancements for issues identified after the release of v1.0.4
Users of prior versions are advised to upgrade to this version. New users are advised to install only this version.
Fixes
- fix(csi-node): cherry-pick wait until filesystem shutdown before disconnect
- Sometimes after/during disconnect we get some page write errors, triggered by a journal
update by the JBD2 worker task.
To get around these, we now wait until the filesystem&jbd2 is shutdown before disconnecting.
- Sometimes after/during disconnect we get some page write errors, triggered by a journal
- fix(csi-node): cherry-pick add noddy sleep between umount and disconnect
- WA for page read errors due to ENXIO. There seems to be some race in the kernel when removing a device with queued IOs.
Although an ugly WA, sleeping between umount and disconnect seems to alleviate this.
- WA for page read errors due to ENXIO. There seems to be some race in the kernel when removing a device with queued IOs.
- fix(csi-node): cherry-pick don't detach if mounts are present
- Eliminates a race condition where detaches were being done even when a device had mount points.
- fix(nvmx): reentrant controller event notification
- Eliminates a potential deadlocks when event listener being notified indirectly triggers the second event notification
action for the same NVMe controller.
- Eliminates a potential deadlocks when event listener being notified indirectly triggers the second event notification
- feat(grpc): per nexus instance locks in grpc api
- Nexus gRPC API is now protected on per-nexus basis instead of global API serialisation, which provides better scalability.
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.4_LTS (kernel: ubuntu-5.15.0-50-generic)
- Tested k8s versions
- 1.23.7
Known Issues
-
The Pool Operator is unable to provision pools directly using a file as the backing device. The operator attempts to validate any device path supplied in the pool specification as an accessible block device attached to the corresponding Mayastor node. In the case of a file store, there is no block device and the validation fails, causing provisioning of the pool to be aborted. This will be addressed in a future release
- workaround: Mount the file/image as a loopback device (
losetup
) and use the device path of the loopback device in the pool spec
- workaround: Mount the file/image as a loopback device (
-
Deploying an application pod on a worker node which hosts both Mayastor and Prometheus exporter causes that node to restart.
- workaround: Use kernel version 5.13 or later
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.4 should be removed prior to installing this version.
Upgrades are disruptive - data plane and control plane pods must be unscheduled, and hence all applications using Mayastor volumes must be stopped prior to performing the update. The upgrade process is manual. The K8s definition files corresponding to the deployment of Mayastor components should be patched to reflect the versions of images from this release (see the /deploy) folder in the appropriate repositories and/or the GitBook Quickstart instruction for details of which definition files are affected, and check the v1.0.3 versions to find the appropriate image tag values.
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
v1.0.4
Release v1.0.4
Release Date: 10th November 2022
Summary
This patch release contains important fixes and supportability enhancements for issues identified after the release of v1.0.3
Users of prior versions are advised to upgrade to this version. New users are advised to install only this version.
Fixes
- fix(nexus): relaxed error unwraps in nexus destroy
- Eliminates a panic which happens upon unconditional unwrap of the result of NVMe subsystem unsharing.
- fix(csi-node): don't unstage if bind mount exists
- Adds a check on node_unstage for unknown mounts (as in, not a csi publish mount). Should there be any we output this as a trace and simply fail the unstage. It's up to the user to clean up non-csi mounts, otherwise we can never unstage.
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.4_LTS (kernel: ubuntu-5.15.0-50-generic)
- Tested k8s versions
- 1.23.7
Known Issues
-
The Pool Operator is unable to provision pools directly using a file as the backing device. The operator attempts to validate any device path supplied in the pool specification as an accessible block device attached to the corresponding Mayastor node. In the case of a file store, there is no block device and the validation fails, causing provisioning of the pool to be aborted. This will be addressed in a future release
- workaround: Mount the file/image as a loopback device (
losetup
) and use the device path of the loopback device in the pool spec
- workaround: Mount the file/image as a loopback device (
-
Deploying an application pod on a worker node which hosts both Mayastor and Prometheus exporter causes that node to restart.
- workaround: Use kernel version 5.13 or later
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.3 should be removed prior to installing this version.
Upgrades are disruptive - data plane and control plane pods must be unscheduled, and hence all applications using Mayastor volumes must be stopped prior to performing the update. The upgrade process is manual. The K8s definition files corresponding to the deployment of Mayastor components should be patched to reflect the versions of images from this release (see the /deploy) folder in the appropriate repositories and/or the GitBook Quickstart instruction for details of which definition files are affected, and check the v1.0.3 versions to find the appropriate image tag values.
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
v1.0.3
Release v1.0.3
Release Date: 11th October 2022
Summary
This patch release contains important fixes and supportability enhancements for issues identified after the release of V1.0.2
Users of prior versions are advised to upgrade to this version. New users are advised to install only this version.
Fixes
- fix: make unmount not lazy
- on removing the MNT_DETACH flag, the unmount operation is no longer lazy
- fix(nexus): shutdown nexuses upon graceful shutdown
- Upon graceful I/O agent shutdown all nexuses are now also properly
shutdown (clear shutdown flag is set to ‘true’ and persisted in ETCD)
- Upon graceful I/O agent shutdown all nexuses are now also properly
- fix: trace errno in lvol destroy error message
- return verbose errors in the grpc status for the catch all internal errors
Supportability Enhancements
- feat(reactor): freeze detection support for reactors
- Introduces a reactor (I/O poller) heartbeat to enable detection of stall conditions, which may block processing of I/O
- A new CLI command
--diagnose-stack
has been added, which allows stack trace collection during such a condition
- feat(nvmf_target): allow users to specify selection logic for the NIC used for I/O traffic
- Allows Mayastor NVMe-oF TCP traffic to be directed through a specific interface on worker nodes
- Selection may be via: subnet_mask, nic_name, or ip_addr
- feat(io-engine): printing configuration on io-engine startup
- The configuration struct of the Mayastor process is dumped to std_out on startup
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.4_LTS (kernel: ubuntu-5.13.0.27-generic)
- Tested k8s versions
- 1.23.7
Known Issues
-
The Pool Operator is unable to provision pools directly using a file as the backing device. The operator attempts to validate any device path supplied in the pool specification as an accessible block device attached to the corresponding Mayastor node. In the case of a file store, there is no block device and the validation fails, causing provisioning of the pool to be aborted. This will be addressed in a future release
- workaround: Mount the file/image as a loopback device (
losetup
) and use the device path of the loopback device in the pool spec
- workaround: Mount the file/image as a loopback device (
-
Deploying an application pod on a worker node which hosts both Mayastor and Prometheus exporter causes that node to restart.
- workaround: Use kernel version 5.13 or later
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.3 should be removed prior to installing this version.
Upgrades are disruptive - data plane and control plane pods must be unscheduled, and hence all applications using Mayastor must be volumes stopped prior to performing the update. The upgrade process is manual. The k8s definition files corresponding to the deployment of Mayastor components should be patched to reflect the versions of images from this release (see the /deploy) folder in the appropriate repositories and/or the GitBook Quickstart instruction for details of which definition files are affected, and check the v1.0.3 versions to find the appropriate image tag values.
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
v1.0.2
Release v1.0.2
Release Date: 4th August 2022
Summary
This patch release contains important fixes for issues identified after the release of V1.0.1
Users of V1.0.1 are advised to upgrade to this version. New users are advised to install only this version.
Features
- feat(rebuild): system-wide maximum
- Introduce a system-wide maximum number of rebuilds. The maximum is
specified as an argument (max_rebuilds) to the core agent. If a maximum
is not specified, the number of rebuilds will not be limited. This
behaviour ensures backwards compatibility.
- Introduce a system-wide maximum number of rebuilds. The maximum is
Fixes
- chore: increase default number of max nvme namespaces per node to 2000
- fix: volume creation failed in eks cluster due to different hostname and nodename
- fix(nexus): serialised nexus i/o suspend/resume
- Suspend/resume operations on NVMe subsystems are now serialised for nexuses,
which properly handles simultaneous I/O suspension/resume operations
in case multiple replicas get retired at the same time.
- Suspend/resume operations on NVMe subsystems are now serialised for nexuses,
- feat(version): unified version display
- 'version-info' module is used to display version uniformely for all binaries.
- fix: change v0/create_pool to idempotent
- change the create_pool() call in v0 version of the grpc idempotent.
Now, if a pool creation is tried for an existing pool, the pool will
be returned instead of an error
- change the create_pool() call in v0 version of the grpc idempotent.
- fix: fix error message when different pool found
- Previously when the name of the pool on the disk, and the name of
pool we are trying to import mismatches, the error message contains
wrong pool name. This change fixes the pool name in case of an errored
pool import
- Previously when the name of the pool on the disk, and the name of
- chore: add env variable to allow qpair async connect
- Add NVME_QPAIR_CONNECT_ASYNC env variable, which defaults to false;
If enabled then the qpair connection is async.
- Add NVME_QPAIR_CONNECT_ASYNC env variable, which defaults to false;
- fix(etcd): pin chart to a specific commit
- See details here: bitnami/charts#10539
- fix(perf): several perf tunning changes to decrease GET delay
- Improves the performance of the REST API when returning lists of managed objects e.g. volumes
- fix: delete resources pending deletion when the store is online
- When the persistent store (etcd) is not online, we may not be able to delete resources. They remain
in the deleting state. Mimic the volume dirty spec reconciler for other resources and simply delete them if the creation
was not successful. Destroy resources in the deleting state from their garbage collection reconciler.
- When the persistent store (etcd) is not online, we may not be able to delete resources. They remain
- fix: clear pending operations for resources on the deleting state
- fix: msp crs going to error state on core and rest restarts
- fix(nodes): don't hold nodes list lock while updating 1 node
- Prevent registrations from other nodes being held by a 'flaky' node
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.4_LTS (kernel: ubuntu-5.13.0.27-generic)
- Tested k8s versions
- 1.21.8
Known Issues
-
The Pool Operator is unable to provision pools directly using a file as the backing device. The operator attempts to validate any device path supplied in the pool specification as an accessible block device attached to the corresponding Mayastor node. In the case of a file store, there is no block device and the validation fails, causing provisioning of the pool to be aborted. This will be addressed in a future release
- workaround: Mount the file/image as a loopback device (
losetup
) and use the device path of the loopback device in the pool spec
- workaround: Mount the file/image as a loopback device (
-
Deploying an application pod on a worker node which hosts both Mayastor and Prometheus exporter causes that node to restart.
- workaround: Use kernel version 5.13 or later
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.
Upgrades from v1.0.1 are disruptive - data plane and control plane pods must be unscheduled, and hence all applications using Mayastor must be volumes stopped prior to performing the update. The upgrade process is manual. The k8s definition files corresponding to the deployment of Mayastor components should be patched to reflect the versions of images from this release (see the /deploy) folder in the appropriate repositories and/or the GitBook Quickstart instruction for details of which definition files are affected, and check the v1.0.1 versions to find the appropriate image tag values.
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 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
V1.0.1
Release v1.0.1
Release Date: 22nd February 2022
Summary
This patch release contains important fixes for issues identified after the release of V1.0.0
Users of V1.0.0 are advised to upgrade to this version. New users are advised to install only V1.0.1
Fixes
- Critical fix(nexus): do not persist faulted state of the last replica
- Replica retirement logic in the nexus allowed the last remaining replica of a volume to be marked as faulted in both the nexus and the persistent store (etcd). If this occurs, even if the device last retired is returned to normal service, the volume remains inaccessible and in a faulted state. This is a terminal condition which the user cannot rectify.
- Major fix(helm chart): remove local pool config store
- The V1.0.0 release incorrectly included a deprecated argument for the Mayastor container in both the prepared daemonset definition file and the Helm chart template from which it is generated. When used, this causes an unexpected duplication of stored configuration between local (file) and remote (etcd) representations.
- fix(nexus): recreate faulted nexuses when appropriate
- If healthy replicas of a faulted nexus are Online, the control plane will now attempt to destroy the faulty instance and recreate a new nexus in order to restore access to the affected volume
- fix(nexus): serialised nexus i/o suspend/resume
- Suspend/resume operations on NVMe subsystems are now serialised for nexuses, which properly handles simultaneous I/O suspension/resume operations in the case where multiple replicas are being retired simultaneously
- chore: add env variable to control max number of qpairs
- Added an environment variable to Mayastor, NVMF_TCP_MAX_QPAIRS_PER_CTRL, to allow control over the maximum number of qpairs per controller. This allows a user to tune the configuration for better stability in scenarios where there is a significant imbalance between the CPU core count used by the Mayastor process and that of the host on which it is scheduled. EXPERIMENTAL USE ONLY
- Sending a node online event should not block
- On startup if the cluster had more than 5 Nodes the send event notification per node would block. This is because the queue has only 5 elements. With this fix, if the queue is full additional events are dropped, which has only marginal impact on startup performance
- fix(jaeger): reduce the OTEL_BSP_MAX_EXPORT_BATCH_SIZE
- Some traces can be too long for export: OpenTelemetry trace error occurred. Exporter jaeger encountered the following error(s): thrift agent failed with message too long. Batch size has been reduced from 512 to 64.
- fix: use dns name to reach rest
- Using the host name created a race as the REST server's node port must start ahead of its consumers. With this fix the DNS name is used, which will be updated whenever REST is ready. Resolves: openebs/mayastor#1076
- fix(node): node status overridden with stale status
- Instead of using a copy of the node to reload, use the node itself with a grpc locked client to update the nodes when the registry is polling Mayastor.
- fix(node): don't stall during (re-)registration of flaky nodes
- Ensure that a node is alive and loaded before adding it to the configuration.
- chore: don't trace reconciliation unless TRACE is set or there is work to do
- For clusters with high number of volumes, the volume of traces can overwhelm the (Open)telemetry exporter. When in reconciliation loops do not create spans needlessly unless TRACE level is set, or unless the reconciler actually did work.
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.3_LTS (kernel: ubuntu-5.13.0.27-generic)
- Tested k8s versions
- 1.21.7
Known Issues
-
The Pool Operator is unable to provision pools directly using a file as the backing device. The operator attempts to validate any device path supplied in the pool specification as an accessible block device attached to the corresponding Mayastor node. In the case of a file store, there is no block device and the validation fails, causing provisioning of the pool to be aborted. This will be addressed in a future release
- workaround: Mount the file/image as a loopback device (
losetup
) and use the device path of the loopback device in the pool spec
- workaround: Mount the file/image as a loopback device (
-
Deploying an application pod on a worker node which hosts both Mayastor and Prometheus exporter causes that node to restart.
- workaround: Use kernel version extra-5.31.0 or later
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 earlier release should be removed prior to installing this version.
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 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
V1.0.0
Release v1.0.0
Release Date: 19th January 2022
Codename: New Horizons
Summary
With this release Mayastor is considered graduated from pre-release / beta status.
Features
-
Complete reimplementation of the control plane, focused on modularity, future extensibility and scaling
- Now written in Rust
- Public RESTful API
- k8s-like reconciliation loop behavior for Mayastor managed objects (volumes, pools)
-
Extensive bug fixing and stabilization
- Supported by 1000's of hours of automated system testing
-
New Mayastor kubectl plugin for management and monitoring
Testing
This release has been subject to E2E system testing by MayaData / DataCore Software, running under Ubuntu 20.04.3_LTS (kernel: ubuntu-5.8.0.63-generic)
- Tested k8s versions
- 1.20.9
- 1.21.8
- 1.22.5
- 1.23.1
Known Issues
-
A Mayastor container may fault and restart if a disk device used by one of its associated disk pools becomes inaccessible. This is currently under investigation, with the intention of providing a fix in the next release.
-
Deploying an application pod on a worker node which hosts both Mayastor and Prometheus exporter causes that node to restart.
- workaround: Use kernel version extra-5.31.0 or later
Getting Started
Mayastor user documentation, including a quick deployment guide, can be found here
Upgrade
Upgrades from previous versions of Mayastor are not supported. Any earlier release should be removed prior to installing this version. It is intended that releases forward of v1.0.0 will allow in-place upgrades.
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
v0.8.1-beta
Various stability fixes
v 0.8.0-beta
Release v0.8.0
Release Date: 15th March 2021
Codename: March Hare
Summary
Incremental/Patch Release
OpenEBS Mayastor is considered beta software. Please deploy accordingly.
Changelog (Highlights)
Features
feat: build against SPDK 21.01
feat: unify mayastor-client address/port flags
feat(nexus): allow shared replica to be added as local child
feat: make bdev share protocol argument as an option
feat: make bdev create parameters strict
feat(nexus): implement set ANA state for an NVMf-published Nexus
feat(nexus): implement get ANA state for an NVMf-published Nexus
feat: show kernel nvme initiator multipath status on startup
docs: add requirements for running with ANA
Fixes
fix(mayastor): fallible replica share (CAS-714)
fix: correct dead links in build docs
fix: update CSI sidecars used with mayastor CAS-651
fix: correct safety of maya_log
fix: try to log the full spdk msg
fix: mayastor-client nexus create accept many children
fix(moac): mayastor pool state is shown as blank
fix: maintain consistency with other args
fix(nexus): mayastor hangs when creating a nexus if there is an error
fix(composer): update separator for security options
fix(csi): update CSI external provisioner to 2.1.1
Chores
refactor(json): tweak the jsongrpc methods
refactor(deployer): split into library and binary
chore(deps): bump systeminformation
chore(nightly): update nix rust nightly
revert: remove rust-toolchain
refactor(nexus): clean up label parsing code
chore: upgrade bindgen to 0.57
chore: do profile-based yaml generation
chore(operators): purge rust operator from repo
chore: finangle multi ISA builds
chore: re-enable on x86_64
chore: compat finangling
chore: update docs
chore: fix cli tests to use -b
chore: clean up and refine spdk use
chore: touchup log wrapper lints and comments
chore: formatting nits
refactor(ctrlp): add core agent
chore: fixup core_6 test failure
chore: remove control plane from mayastor
test(cargo): verify unmap operation for aio module
test: uring add and removal
test(local): add compose override flags
Experimental (Work in progress, unsupported, exposed interfaces may be brittle)
feat(rest): expose list_block_devices method
feat(rest client): add support for new rest calls
feat(rest): authenticate clients
feat(rest-test): new rest test project
chore(rest): add openapi spec to the tree
refactor(rest_cli): improve rest client errors
fix(ci): openapi-check should fail
fix(openapi): parameter names should match
test(rest): add more tests using rest
feat: enable nix-shell on aarch64
feat: enable cargo build on aarch64
feat: aarch64 passing tests
chore: try to enable cross builds
chore: delay cross builds
Testing
This release has been subject to E2E testing by MayaData. Worker nodes ran Ubuntu 20.04.2 LTS, using the docker runtime 20.10.5 under Kubernetes version 1.19.8
Known Issues
Mayastor may fault during the retirement of a nexus child. This is currently under investigation.
Getting Started
Mayastor user documentation, including a quick deployment guide, can be found here
Upgrade
Upgrades from previous versions of Mayastor are not supported. Any earlier release should be removed prior to installing this version. For testing purposes, it is preferable to install to a new, clean cluster.
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
v 0.7.1-beta
Release v0.7.1
Release Date: 12th February 2021
Codename: lunar oxen
Summary
Patch Release
OpenEBS Mayastor is considered beta software. Please deploy accordingly.
Changelog (Highlights)
Fixes
fix(nvmeadm): remove unwrap from disconnect
fix(csi): remove csi-driver-registrar prestop hook
fix(moac): serialize volume creation
fix(nexus): allow re-adding child removed by AEN
fix(nexus): replace NexusChild destroying flag with child state
fix(nexus): set children to destroying state on shutdown
fix(moac): sync replicas more often
refactor(moac): drop support for NBD in CSI
refactor(nexus): add nexus create log
refactor(ctrl-plane): tidy up the control-plane
refactor(nix): control plane nix derivations
Documentation
chore: add CONTRIBUTING.md
feat: rework build docs
Experimental (Work in progress, unsupported)
feat(openapi): generate openapi spec for rest
feat(swagger_ui): expose swagger-ui on rest
feat(deployer): new tool to test the control plane
feat(deployer): ability to deploy JsonGrpc service
feat(rest): expose json rpc methods
feat(control plane): allow images to be built
refactor(rest): add cmdline certificate arguments
refactor(rest): improve rest versions
Getting Started
Mayastor user documentation, including a quick deployment guide, can be found here
Upgrade
Upgrades from previous versions of Mayastor are not supported. Any earlier release should be removed prior to installing this version. For testing purposes, it is preferable to install to a new, clean cluster.
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
v 0.7.0-beta
Release v0.7.0
Release Date: 25th January 2021
Codename: timorous beastie
Summary
Maintenance Release
OpenEBS Mayastor is considered beta software. Please deploy accordingly.
Changelog
To follow (work in progress)
Getting Started
Mayastor user documentation, including a quick deployment guide, can be found here
Upgrade
Upgrades from previous versions of Mayastor are not supported. Any earlier release should be removed prior to installing this version. For testing purposes, it is preferable to install to a new, clean cluster.
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