Release Notes

v0.2.27

Release date: 2026-09-09

A node whose repositories cannot install the iSCSI stack now gets it from the module’s own package image, an HPEStorageClass can reserve a share of the filesystem for the superuser, and the deadlock that left single nodes with no working node plugin is fixed.

Highlights

Changes in this release:

• The module installs open-iscsi and multipath-tools from its own package image when a node’s repositories cannot provide them. Such a node used to be left as it was, and every attach on it then failed, minutes into mounting a volume, with chroot: failed to run command 'iscsiadm'.
• An HPEStorageClass can ask for a share of the filesystem to be kept for the superuser — the classic ext4 reserve — with the storage.deckhouse.io/ext4-reserved-percent annotation. Unless it is asked for, ext4 volumes are now formatted with no reserve at all, where before they lost ext4’s default 5%.
• A restart of node-driver-registrar no longer wedges the node plugin. That deadlock left one or two nodes of a cluster without csi.hpe.com in their CSINode, unable to attach a volume, while their siblings were fine.

New features

This release adds:

• A node whose package repositories cannot install open-iscsi and multipath-tools now gets them from the module’s own iscsi-tools package image: the payload lands under /var/lib/deckhouse/sds/csi-hpe, every binary runs against its own library path, and two units come up for the daemons, d8-csi-hpe-iscsid.service and d8-csi-hpe-multipathd.service. The distribution’s packages stay the preferred path and the two never mix — a node that has an iscsiadm of its own keeps everything of its own, because a client of one version does not speak to an iscsid of another. An /etc/iscsi/initiatorname.iscsi the node already has is left alone, so the node keeps the IQN the array knows it by. Everything else the module configures applies to such a node exactly as to any other, the find_multipaths no the driver depends on to see a device-mapper map at all included.
• storage.deckhouse.io/ext4-reserved-percent on an HPEStorageClass sets the percentage of the filesystem kept for the superuser: a whole number from 0 to 50, default 0. The value reaches the driver as the fsCreateOptions parameter of the managed StorageClass, because a CSI driver never sees the annotations of a StorageClass. Without the annotation the module now says -m0 explicitly, where a bare mkfs.ext4 used to keep ext4’s default 5%. The reserve applies to volumes created afterwards — an existing filesystem keeps the reserve it was created with — and only to ext4: a class with fsType: xfs is unaffected, since XFS keeps no blocks for the superuser. An invalid value leaves the HPEStorageClass with Ready=False and the reason in its status, instead of breaking volume creation later.
• The module setting logLevel sets how much the controller logs: ERROR, WARN, INFO, DEBUG or TRACE, INFO by default.
• The controller exports metrics and a ServiceMonitor puts them in front of the cluster’s main Prometheus: what controller-runtime reports for every controller of the module — reconcile counts and durations, workqueue depth, client-go latency. The controller binds its metrics endpoint on 127.0.0.1, and a kube-rbac-proxy in the same pod authorises every scrape.

Fixes

This release fixes:

• A restart of node-driver-registrar no longer takes the CSI driver with it. The csi-node liveness probe watched a port the registrar serves but was attached to the driver container, and the two deadlocked: the registrar exits by design when registration fails, its port goes with it, the probe kills the driver, the CSI socket disappears, and the restarted registrar can no longer reach it. Nodes came up with the node plugin wedged — a dozen restarts and no csi.hpe.com in their CSINode, so no volume could be attached there — while other nodes of the same cluster were fine. The probe now sits on the container that serves it.
• A change to the multipath configuration no longer fails on a node where multipathd is enabled but not started: such a unit refuses a reload outright, the node configuration step then retried forever, and the module’s find_multipaths no never reached the daemon — which is what decides whether a single-path LUN gets a device-mapper map at all. The handler restarts the unit when it cannot reload it, and covers the module’s own d8-csi-hpe-multipathd.service as well.

Upgrade notes

Before upgrading, note the following:

• Every StorageClass managed by an HPEStorageClass whose fsType is ext4 gains the fsCreateOptions: -m0 parameter on upgrade. Because parameters of an existing StorageClass are immutable in Kubernetes, the controller recreates the class once, on its own. Existing volumes, PVCs and their data are not affected, and a volume created before the upgrade keeps the reserve its filesystem was created with. Nothing has to be done by hand.

Docs

Documentation changes:

• A FAQ entry describes both ways the iSCSI stack reaches a node — the node’s own repositories and the module’s package image: which path is preferred and why, what the fallback puts on the node and where, how to tell from a node which of the two it took, and the two things the fallback deliberately leaves alone.
• A FAQ entry describes the share of a volume kept for the superuser: the annotation, the range of values, that the reserve applies only to volumes created afterwards, and that a class with fsType: xfs is unaffected.
• The Russian reference for HPEStorageClass matches the schema again: the fields are storageConnectionName and fsType, and accessProtocol and cpg were missing from it altogether. spec.controlPlane.address of an HPEStorageConnection is now documented as deprecated in favour of backendAddress. Both CRD manifests are generated from the Go API types, so the schema and its reference cannot drift apart again.

v0.2.26

• Bugfix: the controller is granted patch on events instead of list - a repeated event write is no longer denied by RBAC
• Optional resources are enabled based on the presence of the CRD in the API, not on the list of enabled modules - the checks are routed through helm_lib_api_version_exists
• CVE fixes
• Base images updated to v2.1.2, Go to 1.26.6 and lib-helm to 1.72.14

v0.2.25

• HPEStorageClass and HPEStorageConnection publish status.conditions and status.observedGeneration, added Ready column. The status.phase field retains the same set of values, but is now calculated from the Ready condition
• Fix: nodes now force find_multipaths no via a dedicated /etc/multipath/conf.d/99-deckhouse-csi-hpe-defaults.conf file, so a LUN exposed over a single path still gets a multipath device and volume staging no longer fails with “device not found with serial”
• Fix: the primera3par-csp and nimble-csp Pods are no longer pinned to a failed node — the tolerations that indefinitely tolerated not-ready and unreachable were removed, so the Deployment reschedules onto a healthy node
• Update base images to v1.3.25, Go 1.26.5 and lib-helm to 1.72.13

v0.2.24

• The snapshot-controller module is no longer a required dependency: VolumeSnapshotClass is created only if the snapshot.storage.k8s.io CRD is present, otherwise HPEStorageConnection is processed without the snapshot part
• Update base images, Go 1.26.5 and lib-helm to 1.72.12
• Fixed a vulnerability in gRPC (GHSA-hrxh-6v49-42gf)
• Internal changes in module assembly

v0.2.23

• Update base images, Go 1.26.5 and lib-helm to 1.72.10
• Internal changes in module assembly

v0.2.22

• Fix: Deckhouse registry access secrets are now limited to the active image source
• Update base images, Go 1.26.5 and lib-helm to 1.72.9
• Internal changes in module assembly

v0.2.21

• Updating container-base images to v1.1.2

v0.2.20

• Transition of the csi-hpe runtime image to the distroless base

v0.2.19

• When forwarding labels from HPEStorageClass to StorageClass, labels with specified ignored prefixes are now excluded
• Update base images and lib-helm to 1.72.0

v0.2.18

• Labels from HPEStorageClass are now forwarded to the managed StorageClass Kubernetes
• Update base images, Go 1.25.10 and lib-helm 1.71.12

v0.2.17

• Internal changes in the structure and assembly of the module

v0.2.16

• Update base images, Go 1.25.10 and lib-helm 1.71.11
• Internal changes to the module assembly

v0.2.15

• Corrections to the module structure

v0.2.14

• Changes in CI: DistroPackagesProxy and env proxy in werf, improvements to CVE scans (role_name, checkout)
• Added user-authz cluster roles in templates

v0.2.13

• Installing packages in NodeGroupConfiguration no longer causes the script to crash on errors

v0.2.12

• Added infrastructure and missing mount points for distroless images
• Update base images, Go and lib-helm (CVE fix)

v0.2.11

• Update base images and golang version
• Updated hooks that work when a module is removed
• Disabled Capacity request from k8s (CSI does not support issuing Capacity)
• Fixes in NGC preparing nodes
• Corrections in module manifests

v0.2.10

• Update CSI version to v3.0.0
• Switch from yum to dnf for package installation on CentOS-like distributions
• Fix CVE
• Updated documentation
• Fix VolumeSnapshotClass annotation in StorageClasses

v0.2.9

• Updated base images versions

v0.2.8

• Updated Go version to 1.24.9
• Updated lib-helm to deckhouse_lib_helm-1.64.1

v0.2.7

• Technical release, internal module improvements

v0.2.6

• Technical release, internal module improvements

v0.2.5

• Added release notes

v0.2.4

• Added additional mountings for containerd v2 support

v0.2.3

• Added information about the need for snapshot-controller for module operation
• Added readonlyRootFilesystem for enhanced module security

v0.2.2

• Added dependency on snapshot-controller

v0.2.1

• Technical release, internal module improvements

v0.2.0

• Complete module refactoring
• Documentation fixes
• CVE fixes, except GHSA-m425-mq94-257g in CSI, requiring long-term dependency analysis (planned)
• CVE-2025-22869 in proprietary binary file

v0.1.4

• Added Deckhouse version requirements (>= 1.67)