Release Notes

v0.2.28

Release date: 2026-10-01

The HPE CSI Driver and both CSPs move to v3.3.0, every node now gets the iSCSI stack it lacks from the module’s own package without asking the distribution’s repositories, and the module grants its permissions in the capability/scope RBAC model of DKP 1.78.

Highlights

Changes in this release:

• The HPE CSI Driver and both Container Storage Providers, alletra-9000-primera-and-3par-csp and alletra-6000-and-nimble-csp, are updated from v3.1.0 to v3.3.0, with upstream fixes for attach, detach and multipath handling and for memory use of the CSP.
• The NodeGroupConfiguration no longer asks the node’s package manager for open-iscsi, multipath-tools and sg3-utils. Every node gets the module’s iscsi-tools package, which keeps what the host has and supplies only what it lacks, so a node with no route to its repositories no longer waits out the package manager on every bashible run.
• On DKP 1.78 and later the module’s access roles are d8:system-capability:csi-hpe:view and d8:system-capability:csi-hpe:edit of the capability/scope model; below 1.78 the module keeps d8:manage:permission:module:csi-hpe:view and d8:manage:permission:module:csi-hpe:edit.

New features

This release adds:

• On DKP 1.78 and later the module renders the ClusterRoles d8:system-capability:csi-hpe:view (read HPEStorageClass and HPEStorageConnection) and d8:system-capability:csi-hpe:edit (create, update and delete them) with rbac.deckhouse.io/kind: capability and rbac.deckhouse.io/scope: system, so DKP aggregates them into the storage viewer and manager roles of its new RBAC model. The module picks the model from the DKP version of the cluster; on clusters below 1.78 the roles stay d8:manage:permission:module:csi-hpe:view and d8:manage:permission:module:csi-hpe:edit, unchanged.

Improvements

This release improves:

• The iSCSI stack on a node comes only from the module’s own iscsi-tools package. The package decides for each pair separately — iscsiadm with iscsid, multipath with multipathd: a pair the host has of its own stays the host’s and only the distribution’s unit is enabled, a pair the host lacks is installed under /var/lib/deckhouse/sds/csi-hpe with a unit of the module’s. A host with open-iscsi but without multipath-tools therefore gets the module’s multipathd, where the package used to step aside as soon as the host had an iscsiadm. The find_multipaths no setting and the 3PAR device block reach every node, whichever multipathd runs there. sg3-utils is no longer installed: the driver does not call any of its tools.
• When the tools of a node change after the package was installed — the host lost iscsiadm or multipathd, or the distribution’s package was installed next to the module’s — the NodeGroupConfiguration runs the package’s install again, so the node neither stays without a tool nor runs two daemons side by side until the next module release.

Fixes

This release fixes:

• An upgrade of the iscsi-tools package no longer loses track of the files an earlier version put outside its directory — the iscsiadm wrapper in /usr/local/sbin and the multipath path checkers in /usr/lib/multipath. They used to be taken for the host’s own after an upgrade and were never removed when the package was uninstalled; now they are refreshed and removed with the package.

Security updates

Security updates in this release:

• The csi-driver binary is built with google.golang.org/grpc v1.83.2 (was v1.82.1), which closes CVE-2026-84303, CVE-2026-84304 and CVE-2026-84445, and with golang.org/x/crypto v0.56.0 (was v0.53.0), which closes CVE-2026-56854, CVE-2026-56855 and CVE-2026-78662.

Upgrade notes

Before upgrading, note the following:

• A node that already has open-iscsi and multipath-tools from its distribution keeps them and their units; nothing is removed from it, sg3-utils included. A node added after the upgrade no longer gets these packages from the distribution’s repositories: whatever it lacks comes from the module’s package, so d8-csi-hpe-iscsid.service or d8-csi-hpe-multipathd.service runs there instead of the distribution’s iscsid or multipathd.
• On DKP 1.78 and later the ClusterRoles d8:manage:permission:module:csi-hpe:view and d8:manage:permission:module:csi-hpe:edit are replaced by d8:system-capability:csi-hpe:view and d8:system-capability:csi-hpe:edit. Access granted through the storage roles of DKP keeps working; a RoleBinding or ClusterRoleBinding that names one of the old roles directly has to be switched to the new name.

Docs

Documentation changes:

• A FAQ entry describes where open-iscsi and multipath-tools on a node come from: how the package decides for each pair, which files it puts outside its directory and when it takes them back, and how to tell from a node which daemons are the host’s and which are the module’s.
• The spec field of HPEStorageClass has an English description in the CRD reference; only the Russian one had it before.

Dependencies

Dependency updates:

• HPE CSI Driver for Kubernetes: 3.1.0 → 3.3.0 (changelog)
  • Among the upstream fixes: a detach or attach of a PVC no longer detaches or re-enumerates an unrelated multipath device on the node; a multipath map with no path groups left after a SAN switch failure is flushed with multipath -f instead of a forced dmsetup remove; lower memory use of the node plugin when listing multipath devices.
• alletra-9000-primera-and-3par-csp: 3.1.0 → 3.3.0 (changelog)
  • Serves HPEStorageConnection with storageType: Primera3Par. Among the upstream fixes: a publish that fails because the host object on the array was deleted concurrently no longer records LunId=-1 and blocks every later attach of the volume; ControllerUnpublishVolume no longer leaves a stale export that blocks deleting the volume; the CSP Pod is no longer OOM-killed over and over because of excessive logging; a PVC can be cloned to a larger size than its source.
• alletra-6000-and-nimble-csp: 3.1.0 → 3.3.0 (changelog)
  • Serves HPEStorageConnection with storageType: NimbleAlletra.

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)