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.

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.
• 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
• 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
• 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.
• 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.
• 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

• 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