SUSE Storage v1.9.1 Release Notes

This release introduces several improvements and bug fixes that are intended to improve system quality, resilience, stability and security. The documentation is available at SUSE Storage Documentation.

For more information about release-related terminology, see Releases.

Removals

Environment check script

The environment_check.sh script, deprecated in v1.7.0, has been removed in v1.9.0. Use the SUSE Storage Command Line Tool (longhornctl) to check your environment for potential issues.

Orphan resource auto-deletion

The orphan-auto-deletion setting has been replaced by orphan-resource-auto-deletion in v1.9.0. To replicate the previous behavior, include replica-data in the orphan-resource-auto-deletion value. During the upgrade, the original orphan-auto-deletion setting is automatically migrated.

For more information, see Orphan Data Cleanup.

Deprecated fields in longhorn.io/v1beta2 CRDs

Deprecated fields have been removed from the CRDs. For details, see #6684.

Deprecations and Incompatibilities

longhorn.io/v1beta1 API

The v1beta1 version of the SUSE Storage API is marked unserved and unsupported in v1.9.0 and will be removed in v1.10.0.

For more details, see #10250.

Breaking change in V2 backing image

Starting with SUSE Storage v1.9.0, V2 backing images are incompatible with earlier versions due to naming conflicts in the extended attributes (xattrs) used by SPDK backing image logical volumes. As a result, V2 backing images must be deleted and recreated during the upgrade process. Since backing images cannot be deleted while volumes using them still exist, you must first back up, delete and later restore those volumes as the following steps:

  • Before upgrading to v1.9.0:

    • Verify that backup targets are functioning properly.

    • Create full backups of all volumes that use a V2 backing image.

    • Detach and delete these volumes after the backups complete.

    • In the Backing Image page, save the specifications of all V2 backing images, including the name and the image source.

    • Delete all V2 backing images.

  • After upgrading:

    • Recreate the V2 backing images using the same names and image sources.

    • Restore the volumes from your backups.

For more details, see #10805.

Primary Highlights

New V2 Data Engine features

While the V2 Data Engine remains experimental in this release, several core functions have been improved:

  • Support UBLK Frontend: Support for UBLK front-end in the V2 Data Engine, which allows for better performance and resource utilization.

  • Storage Network: Introduces support for storage networks in the V2 Data Engine to allow network segregation.

  • Offline Replica Rebuilding: Support for offline replica rebuilding, which allows degraded volumes to automatically recover replicas even while the volume is detached. This capability ensures high data availability without manual intervention.

Recurring system backup

Starting with SUSE Storage v1.9.0, you can create a recurring job for system backup creation.

Documentation | #6534

Offline replica rebuilding

SUSE Storage introduces offline replica rebuilding, a feature that allows degraded volumes to automatically recover replicas even while the volume is detached. This capability minimizes the need for manual recovery steps, accelerates restoration, and ensures high data availability. By default, offline replica rebuilding is disabled. To enable it, set the offline-replica-rebuilding setting to true in the SUSE Storage UI or CLI.

Documentation | #8443

Orphaned instance deletion

SUSE Storage can now track and remove orphaned instances, which are leftover resources like replicas or engines that are no longer associated with an active volume. These instances may accumulate due to unexpected failures or incomplete cleanup.

To reduce resource usage and maintain system performance, SUSE Storage supports both automatic and manual cleanup. By default, this feature is disabled. To enable it, set the orphan-resource-auto-deletion setting to instance in the SUSE Storage UI or CLI.

Documentation | #6764

Improved metrics for replica, engine, and rebuild status

SUSE Storage improves observability with new Prometheus metrics that expose the status and identity of Replica and Engine CRs, along with rebuild activity. These metrics make it easier to monitor rebuilds across the cluster.

For more information, see #10550 and #10722.

Installation

Ensure that your cluster is running Kubernetes v1.25 or later before installing SUSE Storage v1.9.1.

You can install SUSE Storage using a variety of tools, including SUSE® Rancher Prime, Kubectl, and Helm. For more information about installation methods and requirements, see Quick Installation in the documentation.

Upgrade

Ensure that your cluster is running Kubernetes v1.25 or later before upgrading from SUSE Storage v1.8.x or v1.9.x (< v1.9.1) to v1.9.1.

SUSE Storage only allows upgrades from supported versions. For more information about upgrade paths and procedures, see Upgrade in the documentation.

Post-release Known Issues

For information about issues identified after this release, see Release-Known-Issues.

Resolved Issues

Feature

  • #11068 [BACKPORT][v1.9.1][FEATURE] Standardized way to override container image registry

  • #11072 [BACKPORT][v1.9.1][FEATURE] Standardized way to specify image pull secrets

Improvement

  • #11280 [BACKPORT][v1.9.1][IMPROVEMENT] Remove the Patch preserveUnknownFields: false for CRDs

  • #11212 [BACKPORT][v1.9.1][IMPROVEMENT] Improve the disk space un-schedulable condition message

  • #11196 [BACKPORT][v1.9.1][IMPROVEMENT] Improve the condition message of engine image check

  • #11225 [BACKPORT][v1.9.1][IMPROVEMENT] Improve the logging when detecting multiple backup volumes of the same volume on the same backup target

  • #11168 [BACKPORT][v1.9.1][IMPROVEMENT] extra invalid BackupVolumeCR may be created during cluster split-brain

  • #11069 [BACKPORT][v1.9.1][IMPROVEMENT] Full replica rebuilding when a node goes down for a while and then comes back

  • #10914 [BACKPORT][v1.9.1][IMPROVEMENT] Adding retry logic for longhorn-csi-plugin when it trying to contact the longhorn-manager pods

Bug

  • #11266 [BACKPORT][v1.9.1][BUG] Incorrect value of remove-snapshots-during-filesystem-trim in longhorn chart/values.yaml

  • #11258 [BACKPORT][v1.9.1][BUG] privateRegistry.registryUrl does not work when overriding specific image registries

  • #11235 [BACKPORT][v1.9.1][BUG] system backup error

  • #11184 [BACKPORT][v1.9.1][BUG] Volume expansion fails with "unsupported disk encryption format Ext4"

  • #11217 [BACKPORT][v1.9.1][BUG] The Backup YAML example in the SUSE Storage doc does not work

  • #11164 [BACKPORT][v1.9.1][BUG] CSI Plug-in restart triggers unintended restart of migratable RWX volume workloads

  • #11180 [BACKPORT][v1.9.1][BUG] in the browser UI: Volume - Clone Volume results in the broken browser page

  • #10917 [BACKPORT][v1.9.1][BUG] Test case test_engine_image_not_fully_deployed_perform_volume_operations failed: unable to detach a volume

  • #11170 [BACKPORT][v1.9.1][BUG] Creating support-bundle panic NPE

  • #11162 [BACKPORT][v1.9.1][BUG] Unable to Build Longhorn-Share-Manager Image Due to CMAKE Compatibility

  • #11020 [BACKPORT][v1.9.1][BUG] Recurring jobs fail when assigned to default group

  • #11047 [BACKPORT][v1.9.1][BUG] SPDK API bdev_lvol_detach_parent does not work as expected

  • #11056 [BACKPORT][v1.9.1][BUG] unable to clean up the backing image volume replica after node eviction

  • #11035 [BACKPORT][v1.9.1][BUG] backing image volume replica NPE crash during evicting node

Misc

  • #11140 [HOTFIX] Create hotfixed image for longhorn-manager:v1.9.0

  • #11118 [BACKPORT][v1.9.1][TASK] Ensure support-bundle-kit builds use vendored dependencies