This is unreleased documentation for SUSE® Storage 1.10.0 (Dev).

Important Notes

Please see here for the full release notes.

An incorrect SUSE Storage image tag (v1.8.x-head) was used in the deployment manifest and the Helm chart. The correct tag for SUSE Storage v1.8.0 images is v1.8.0. For more information, see Issue #10336.

If you installed or upgraded SUSE Storage using the deployment manifest or the Helm chart from the main Longhorn repository, perform the following actions to resolve the issue:

  • New installations: Replace v1.8.x-head with v1.8.0 in the deployment manifest or the Helm chart before deploying SUSE Storage.

  • Upgrades: Replace v1.8.x-head with v1.8.0 in the deployment manifest or Helm chart. Next, upgrade the Longhorn system and update the engine image for volumes that use v1.8.x-head.

This issue does not affect installations and upgrades performed using the charts in the Longhorn Helm repository. For more information, see Install with Helm.

Removal

longhorn.io/v1beta1 API

The v1beta1 version of the Longhorn API is removed since Longhorn v1.10.0.

For more details, see Issue #10249.

General

Kubernetes Version Requirement

The upgrade of the CSI external snapshotter to version v8.2.0 requires that all clusters run Kubernetes v1.25 or later. Ensure your Kubernetes version meets this requirement before you upgrade to SUSE Storage v1.8.0 or a newer version.

CRD Upgrade Validation

During an upgrade, the Custom Resource Definition (CRD) might be applied after the new Longhorn Manager starts. This order helps prevent the controller from processing objects that contain deprecated data or fields. However, this sequencing can cause the Longhorn Manager to fail during the initial upgrade phase if the CRD is not yet applied.

If the Longhorn Manager crashes during the upgrade, check the logs to determine if the CRD not being applied is the cause of the failure. In such cases, the logs might contain error messages similar to the following:

time="2025-03-27T06:59:55Z" level=fatal msg="Error starting manager: upgrade resources failed: BackingImage in version \"v1beta2\" cannot be handled as a BackingImage: strict decoding error: unknown field \"spec.diskFileSpecMap\", unknown field \"spec.diskSelector\", unknown field \"spec.minNumberOfCopies\", unknown field \"spec.nodeSelector\", unknown field \"spec.secret\", unknown field \"spec.secretNamespace\"" func=main.main.DaemonCmd.func3 file="daemon.go:94"

Upgrade Check Events

SUSE Storage performs a pre-upgrade check when upgrading with Helm or the Rancher App Marketplace. If a check fails, the upgrade process stops, and the reason for the failure is recorded in an event. For more details, see Upgrading Longhorn Manager.

Manual Checks Before Upgrade

Automated checks are performed only on some upgrade paths, and the pre-upgrade checker might not cover all scenarios. Manual checks, performed using either kubectl or the UI, are recommended for these scenarios. You can then take mitigating actions or defer the upgrade until any identified issues are addressed.

  • Ensure that all V2 Data Engine volumes are detached and their replicas are stopped. The V2 Data Engine currently does not support live upgrades.

  • Avoid upgrading when volumes are in the "Faulted" status. If all replicas are deemed unusable, they might be deleted, potentially leading to permanent data loss if no usable backups exist.

  • Avoid upgrading if a failed BackingImage exists. For more information, see Backing Image.

  • Create a Longhorn system backup before performing the upgrade. This ensures that all critical resources, such as volumes and backing images, are backed up and can be restored if any issues arise during the upgrade.

V2 Data Engine

SUSE Storage System Upgrade

SUSE Storage currently does not support live upgrading of V2 volumes. Ensure that all V2 volumes are detached before initiating the upgrade process.