Release Notes

v0.4.21

Release date: 2026-11-05

Volume snapshots and volumeCleanup work in the SE and SE+ editions, a VolumeSnapshot in Community Edition fails at once instead of hanging, LocalStorageClass reports its state through Events, alerts and a capacity dashboard, and the module images no longer carry the reported golang.org/x/net vulnerabilities.

Highlights

Changes in this release:

• Volume snapshots and spec.lvm.volumeCleanup of LocalStorageClass now work in the SE and SE+ editions; volume cleanup needs sds-node-configurator v0.9.0 or later.
• In Community Edition the module no longer deploys a VolumeSnapshotClass, so a VolumeSnapshot of its volume gets an error in status.error at once instead of waiting forever.
• LocalStorageClass records Events when its Ready condition changes, two new alerts report a class that is not Ready and a node that needs manual eviction, and the Grafana dashboard shows the capacity of each class.

New features

This release adds:

• The “SDS Local Volume” Grafana dashboard shows the capacity of a LocalStorageClass in the new “Capacity by LocalStorageClass” row: pick a class and read the size, free space and share used of its volume groups for a Thick class, or the size of its thin pools, the size allocated to volumes, the allocation limit, the space free by allocationLimit and the share filled with data for a Thin class, in total and per node and LVMVolumeGroup. The free space of a Thin class is the allocation limit less what is allocated to volumes, the same figure the module checks when it creates a volume, so overprovisioning is taken into account. The row is built on the new controller metric sds_local_volume_local_storage_class_lvg_info{storage_class, lvg_name, thin_pool}, which ties every LocalStorageClass to its LVMVolumeGroups and thin pools, and on the LVMVolumeGroup capacity metrics of sds-node-configurator.
• A VolumeSnapshot can be bound to an existing snapshot through a VolumeSnapshotContent created by hand, with spec.source.snapshotHandle set to the name of the LVMLogicalVolumeSnapshot, for example to bring back a snapshot kept by deletionPolicy: Retain. The CSI driver now checks such a handle: the snapshot becomes ready only when the LVMLogicalVolumeSnapshot exists and is Created, and restoreSize is filled in from its status.size. Before, any handle, a mistyped one included, was reported as a ready snapshot with no size, and the error surfaced only when a volume was restored from it. The scenario is described in the module usage documentation. Available in the editions with volume snapshots.
• LocalStorageClass now records a Kubernetes Event when its Ready condition changes status or reason: a Warning when it turns False, a Normal one when it turns True again. The reason of the Event is the reason of the condition — ReconcileFailed, Reconciled, LVMVolumeGroupsOutsideCSINodes or Deleting — so kubectl describe shows when a class broke and when it recovered. Deleting a LocalStorageClass is not a failure: the move to Deleting is recorded as a Normal Event, and a deletion that fails records a Warning one with the reason ReconcileFailed. A reconcile pass that changes nothing records no Event. LocalStorageClass is cluster-scoped, so its Events are in the default namespace.

Improvements

This release improves:

• New alert D8SdsLocalVolumeLocalStorageClassNotReady fires when the Ready condition of a LocalStorageClass has not been True for 15 minutes: the controller could not apply the class (reason: ReconcileFailed), or another controller’s finalizer holds the class in its deletion (reason: Deleting). The alert reads the existing metric sds_local_volume_local_storage_class_ready.
• A LocalStorageClass can no longer be created under the name of a StorageClass that belongs to another provisioner. The module names its StorageClass after the LocalStorageClass, so such a resource used to be created and then stay Failed; the webhook now rejects it at creation and names the StorageClass that holds the name.
• Removing a thin pool from spec.thinPools of an LVMVolumeGroup is now rejected while a LocalStorageClass uses that thin pool, whether the class names the LVMVolumeGroup or selects it by labels. sds-node-configurator removes a thin pool dropped from the spec once it is empty, and the class would then point at a thin pool that is gone. The check does not block LVMVolumeGroup updates while the module’s webhook is unavailable.
• Errors of volume creation and expansion name the LVMVolumeGroup and its node, so the event of a PVC that cannot be provisioned or resized shows where the agent log is to be read. A failure to pick an LVMVolumeGroup now carries its cause, such as the node with no LVMVolumeGroup of the StorageClass. The CSI controller log adds the lvg and node fields to every line of a volume operation once the LVMVolumeGroup is known.
• New alert D8SdsLocalVolumeNodeNeedsManualEviction fires when a node has stayed in the module for 15 minutes after leaving its nodeSelector, because some of its LVMVolumeGroups are still listed in LocalStorageClasses. Such a node carries the storage.deckhouse.io/sds-local-volume-need-manual-eviction label and keeps the CSI node plugin; before, only a warning in the controller log reported it. The alert tells how to find the LVMVolumeGroups and LocalStorageClasses that hold the node and how to release it. It reads the new controller metric sds_local_volume_node_manual_eviction_required{node}.
• A LocalStorageClass that uses LVMVolumeGroups on nodes without the module’s CSI node, that is outside spec.settings.dataNodes.nodeSelector of the module, now says so. Its Ready condition stays True, since the class works on its other LVMVolumeGroups, but carries the reason LVMVolumeGroupsOutsideCSINodes instead of Reconciled, and the message lists such LVMVolumeGroups with their nodes: volumes cannot be used on them. The list is kept current as nodes gain or lose the CSI node. The webhook returns the same text as a warning when such a class is created or updated, without rejecting it. Before, the class came up Ready, and a Pod given a volume on such a group got stuck on a node where nothing served it.

Fixes

This release fixes:

• The CSI controller could create a volume on an LVMVolumeGroup that is not Ready. With volumeBindingMode: Immediate it picked the node with the most free space among all LVMVolumeGroups of the StorageClass, whatever their phase, and with WaitForFirstConsumer it took the LVMVolumeGroup of the chosen node without looking at the phase, which mattered while the scheduler extender, registered with failurePolicy: Ignore, was unavailable. LVMVolumeGroups that are not Ready are now skipped when a node is picked, and a volume is not created on one: the error names the LVMVolumeGroup, its node and its phase.
• With volumeBindingMode: Immediate, an LVM-thin volume bigger than the available space of its thin pool no longer turns into an LVMLogicalVolume that the node fails with not enough space and the CSI controller deletes, again on every retry of the provisioner. The CSI controller compares the request with the available space of the thin pool, which already counts allocationLimit, and leaves the PVC Pending with an event that names the thin pool, its available space and allocationLimit. The error carries the ResourceExhausted code, as do the errors for a Thick volume that does not fit and for a StorageClass whose LVMVolumeGroups have no space left at all; the latter used to fail with no LVMVolumeGroup found for node.
• When the CSI driver fails to delete an LVMLogicalVolumeSnapshot, the deletion of the VolumeSnapshot is retried instead of being reported as done. The error used to be only logged, so the VolumeSnapshotContent went away while the LVMLogicalVolumeSnapshot and its logical volume stayed on the node. A snapshot that is already gone still counts as deleted.
• spec.lvm.volumeCleanup of LocalStorageClass now works in the SE and SE+ editions, as the documentation says it does in every commercial edition. The CSI driver of these editions refused it: a PVC of such a class stayed Pending with volume cleanup is not supported in your edition, and a volume whose class got volumeCleanup later could not be deleted. Volume cleanup is now available in every edition except CE. It needs sds-node-configurator with the same fix, because its agent erases the volume.
• A change of the labels of a StorageClass made by the module is now applied to the existing StorageClass instead of deleting and creating it again. Recreating removed the class for a moment, so a PersistentVolumeClaim that arrived in that window failed to provision. A change of the LVMVolumeGroups or of volumeCleanup still recreates the StorageClass.
• Volume snapshots now work in the SE and SE+ editions. The CSI driver of these editions advertised snapshot support and the module deployed csi-snapshotter, but the snapshot calls of the driver were built into the EE and FE images only, so every VolumeSnapshot stayed not ready with an Unimplemented error. The snapshot code is now built for every edition except CE, the same editions in which sds-node-configurator handles LVMLogicalVolumeSnapshots.
• In Community Edition, a VolumeSnapshot of a volume of the module no longer waits forever without a status. The edition takes no snapshots, but the module still deployed its VolumeSnapshotClass sds-local-volume-snapshot-class and named it in the storage.deckhouse.io/volumesnapshotclass annotation of its StorageClasses, so every VolumeSnapshot got a VolumeSnapshotContent that nothing processed. The class is now deployed and the annotation set only in the editions with snapshots, and in Community Edition the controller removes the annotation from the existing StorageClasses without recreating them. A VolumeSnapshot then gets an error from the snapshot-controller in status.error at once: cannot find default snapshot class, or not found for a VolumeSnapshot that names the class. The FAQ lists the errors and explains how to delete the VolumeSnapshots left hanging from before the update.
• Deleting a LocalStorageClass hung forever when the class stopped passing the webhook checks after it was created, for example when one of its LVMVolumeGroups was deleted first or its storage.deckhouse.io/ext4-reserved-percent annotation was invalid: the webhook rejected the update that removes the controller’s finalizer. A LocalStorageClass being deleted is now let through without checks.
• Expanding a volume whose path had nothing mounted on it was reported as done on the node while the filesystem kept its old size. The CSI node now answers NotFound in this case, so the expansion is reported as failed instead of finished, and for a Block volume it checks that the device exists.
• The storage.deckhouse.io/managed-by label of the StorageClasses the module creates now holds the module name, sds-local-volume, instead of d8-sds-local-volume-storage-class-controller, as in other storage modules. Existing StorageClasses get the new value on the first reconcile after the update, without being recreated.

Security updates

Security updates in this release:

• golang.org/x/net is raised from v0.60.0 to v0.62.0 in the CSI driver, the module controller, the webhooks and the hooks, closing CVE-2026-78661 and CVE-2026-97045. The module images are built on base images v4.0.7.

Upgrade notes

Before upgrading, note the following:

• Existing StorageClasses get the new value of the storage.deckhouse.io/managed-by label on the first reconcile after the update, in place, without being recreated. Label selectors and monitoring queries outside the module that match d8-sds-local-volume-storage-class-controller have to be changed to sds-local-volume.
• In the SE and SE+ editions, spec.lvm.volumeCleanup needs sds-node-configurator v0.9.0 or later, because its agent erases the volume.
• In Community Edition the controller removes the storage.deckhouse.io/volumesnapshotclass annotation from the existing StorageClasses by itself. VolumeSnapshots that were left hanging before the update are not cleaned up automatically: delete them as the FAQ describes.

Docs

Documentation changes:

• The FAQ no longer promises alerts at 20%, 10%, 5% and 1% of free space in a thin pool, which the module does not have. It now explains that overprovisioning is limited by allocationLimit of the thin pool in LVMVolumeGroup (150% by default, 100% turns it off) and names the metrics to monitor the pool with.
• The configuration page has a section on disabling the module: in which order to delete PersistentVolumeClaims and LocalStorageClass resources before disabling it, since the CSI driver reads volumeCleanup from the class when it deletes a volume, and what happens to the volumes left in the cluster.

v0.4.20

Release date: 2026-10-26

The CSI node plugin comes with the SecurityPolicyException that DKP 1.79 requires for system Pods, the CSI sidecars log at the level set by logLevel, and the module images no longer carry the reported Go dependency vulnerabilities.

Highlights

Changes in this release:

• The module ships a SecurityPolicyException for the csi-node DaemonSet in d8-sds-local-volume, so its Pods keep starting once DKP 1.79 switches the Pod Security Standards of system namespaces from warning to denial.

Improvements

This release improves:

• The csi-node DaemonSet gets a SecurityPolicyException that describes each privilege it needs beyond the restricted profile: the privileged node container, the node and node-driver-registrar containers running as root with privilege escalation, and the hostPath volumes for the kubelet directories and /dev. Its Pods carry the security.deckhouse.io/security-policy-exception label pointing to it. The module controller and the CSI controller already fit the restricted profile and get no exception. The object is rendered only when the SecurityPolicyException resource is available in the cluster (the admission-policy-engine-crd module is enabled); on earlier platforms nothing changes.

Fixes

This release fixes:

• The CSI sidecars of the controller and node-driver-registrar ran with a fixed --v=5 whatever logLevel was set to. Their verbosity now follows logLevel: ERROR, WARN, INFO, DEBUG and TRACE give --v=0, 1, 2, 4 and 5. The default INFO gives --v=2, and TRACE keeps the previous level of detail.

Security updates

Security updates in this release:

• Go dependencies of the CSI driver, the module controller, the webhooks and the hooks are updated, which clears CVE-2026-78669, CVE-2026-78659, CVE-2026-78660, CVE-2026-78663, CVE-2026-97032, CVE-2026-56851, CVE-2026-63209 and CVE-2026-85747 from scans of the module images.

Upgrade notes

Before upgrading, note the following:

• Nothing has to be done by hand. The CSI controller and csi-node Pods restart once because of the new log arguments and, where the SecurityPolicyException resource is available, the new label.

v0.4.19

Release date: 2026-10-01

Prometheus now collects the CSI operation metrics from the node plugin as well as from the controller, both served over HTTPS behind an authorization check, and the module’s access roles follow the capability model of DKP 1.78.

Highlights

Changes in this release:

• The sds-local-volume-csi-node scrape job gets targets: before this release Prometheus had no endpoint for the CSI node plugin, so sds_local_volume_csi_operations_total and sds_local_volume_csi_operation_duration_seconds were collected from the CSI controller only.
• On DKP 1.78 and later the module grants access to LocalStorageClass through the d8:system-capability:sds-local-volume:view and d8:system-capability:sds-local-volume:edit roles; on earlier versions the d8:manage:permission:module:sds-local-volume:* roles stay unchanged.

New features

This release adds:

• The module ships ClusterRoles in the capability model of DKP 1.78: d8:system-capability:sds-local-volume:view (get, list and watch on LocalStorageClass) and d8:system-capability:sds-local-volume:edit (create, update, patch, delete and deletecollection), aggregated into the storage viewer and manager roles. The scheme is chosen from the Deckhouse version: on 1.78 and later these roles replace d8:manage:permission:module:sds-local-volume:view and d8:manage:permission:module:sds-local-volume:edit, below 1.78 the previous roles are rendered as before.

Fixes

This release fixes:

• The PodMonitor of the CSI node plugin selected the metrics endpoint by port 8080, which the csi-node container does not declare, so Prometheus had no targets for the sds-local-volume-csi-node job and the CSI operation metrics of the nodes were never collected. Both the CSI controller and the csi-node DaemonSet now carry a kube-rbac-proxy sidecar that publishes the metrics as https-metrics on the Pod address; the driver itself listens on 127.0.0.1 only. A scrape is allowed only for a subject with get on the prometheus-metrics subresource of the csi-controller Deployment or the csi-node DaemonSet, which is granted to the Deckhouse Prometheus. Series of the sds-local-volume-csi-node job now also carry tier: cluster, as those of the controller do, and the terminating Pods of a rolling update are no longer scraped. The job names and metric names do not change. The CSI Pods are restarted by the update.

Upgrade notes

Before upgrading, note the following:

• The CSI metrics are no longer served as plain HTTP on port 8080 of the Pod address. A scraper other than the Deckhouse Prometheus that read them directly has to use HTTPS on the https-metrics port with a token of a subject that holds get on deployments/prometheus-metrics (controller) or daemonsets/prometheus-metrics (node) in d8-sds-local-volume. Nothing has to be done for the built-in monitoring.

v0.4.18

Release date: 2026-09-24

Security update of the CSI driver and the module’s hooks; the CSI Pods no longer use ports from the range reserved for the host network.

Highlights

Changes in this release:

• google.golang.org/grpc is raised from v1.82.1 to v1.83.2 in the CSI driver, closing CVE-2026-84303, CVE-2026-84304 and CVE-2026-84445.

Improvements

This release improves:

• The livenessprobe of the CSI controller and the CSI node plugin no longer uses ports 4250 and 4251, which belong to the 4200–4299 range reserved for modules that listen on the host network; both Pods run in the Pod network, and the probe now uses the default port inside the Pod. The CSI Pods are restarted by the update.

Security updates

Security updates in this release:

• google.golang.org/grpc is raised from v1.82.1 to v1.83.2 in the CSI driver, closing CVE-2026-84303, CVE-2026-84304 and CVE-2026-84445.
• golang.org/x/crypto is raised from v0.53.0 to v0.57.0 in the module’s hooks (go-hooks), closing CVE-2026-56854 (authentication bypass by source address in x/crypto/ssh), CVE-2026-56855 and CVE-2026-78662.

v0.4.17

Release date: 2026-09-15

The module logs at INFO by default instead of DEBUG, so an installation that never chose a level stops writing debug output from its CSI components.

Highlights

Changes in this release:

• logLevel defaults to INFO instead of DEBUG. Where the level was never set in the module configuration, the CSI controller and the node plugin become markedly quieter after the update; setting logLevel: DEBUG brings the previous verbosity back.

Improvements

This release improves:

• The default of logLevel in the module configuration is now INFO. The setting drives LOG_LEVEL of the CSI controller and of the csi-node plugin, so DEBUG as the default meant that every installation which never touched the setting ran its whole data plane at debug verbosity and paid for it in log volume. A logLevel stated explicitly in the ModuleConfig is honoured exactly as before, whatever it says.

Upgrade notes

Before upgrading, note the following:

• Nothing has to be done in the module configuration. Where logLevel is not set, the components come up at INFO as their pods roll out with the update; where it is set, the level stays as configured. To keep the previous behaviour, set logLevel: DEBUG explicitly.

v0.4.16

Release date: 2026-09-09

A LocalStorageClass can reserve a share of the filesystem for the superuser, the csi-node deadlock that left single nodes unable to attach a volume is fixed, and a release of the module is described in sections and in both languages.

Highlights

Changes in this release:

• A LocalStorageClass 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. Volumes keep being formatted with no reserve unless it is asked for.
• A restart of node-driver-registrar no longer wedges the node plugin. That deadlock left one or two nodes of a cluster without the module’s driver in their CSINode, unable to attach a volume, while their siblings were fine.
• A release is described in sections — summary, highlights, new features, improvements, fixes — in English and in Russian, and the console shows the notes in the language of the reader.

New features

This release adds:

• storage.deckhouse.io/ext4-reserved-percent on a LocalStorageClass sets the percentage of the filesystem kept for the superuser: a whole number from 0 to 50, default 0. The value travels through the parameters of the managed StorageClass and the CSI volume context to NodeStageVolume, because a CSI driver never sees the annotations of a StorageClass, and tune2fs applies it there. Only a filesystem that stage call has just created is touched: restaging a volume never rewrites the superblock of a filesystem that already carries data, so a volume keeps the reserve it was created with. The reserve applies to the ext family only — with fsType: xfs the annotation is ignored and the validating webhook says so in a warning — and an invalid value is rejected by that webhook outright, instead of failing every volume of the class at stage time. Changing the annotation makes the controller recreate the StorageClass, because parameters of an existing StorageClass are immutable in Kubernetes; existing volumes and PVCs are not affected.

Improvements

This release improves:

• Release notes are written per locale in .release-notes/<tag>.yaml and <tag>.ru.yaml with the sections summary, highlights, new_features, improvements, fixes, security, breaking, upgrade_notes, known_issues, docs and dependencies. Both locales reach the cluster; the releases cut before this one keep the previous flat format and render on the same page exactly as before.

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. A node came up with the node plugin wedged — a dozen restarts and no driver in its 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 release tag with no release notes used to publish an empty changelog.yaml, leaving ModuleRelease.spec.changelog blank with a green build. Such a tag now fails the build.

Upgrade notes

Before upgrading, note the following:

• Nothing has to be done in the module configuration. A node whose csi-node pod was stuck in the registration deadlock recovers as the DaemonSet rolls out the fixed pod — no pod has to be deleted by hand.

Docs

Documentation changes:

• 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 it is ignored for fsType: xfs.

v0.4.15

• Fix: the release image is no longer built from cache with an outdated changelog.yaml — git-mapping dependencies are bound to the install stage, where the file is copied
• Update base images to v2.1.4 and lib-helm to 1.72.14
• Internal build changes for the module

v0.4.14

• 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
• Internal build changes: CI updated, crds, docs and openapi are shipped in the release image

v0.4.13

• Correction: LVMLogicalVolume and LVMLogicalVolumeSnapshot remaining after removing a PersistentVolume from a StorageClass with reclaimPolicy Retain no longer remain forever - a collector has been added that removes the module finalizer from resources that have already been requested to be deleted and that are not referenced. Previously, the space in the volume group remained occupied, the LVMLogicalVolume delete command did not complete, and the finalizer had to be removed manually
• Added metrics for logical volumes and volumes that have outlived their PersistentVolume, five alerting rules and an “SDS Local Volume” dashboard; describes the procedure for manually freeing up space when reclaimPolicy Retain
• LocalStorageClass publishes status.conditions and status.observedGeneration
• Correction: condition message is truncated to schema-allowed length
• Updating base images to v1.3.25 and lib-helm to 1.72.13

v0.4.12

• The snapshot-controller module is no longer a required dependency: VolumeSnapshotClass is created only if the snapshot.storage.k8s.io API is available
• Added controller and CSI driver metrics (previously the module did not export anything), logging transferred to common Deckhouse libraries
• Correction: the volume size during normal creation is aligned to the LVM extent boundary, the volume capacity and restoreSize of the snapshot are reported according to the actual size of the LV - previously a request for 35Mi gave an LV of 36Mi, described as 35Mi
• Correction: restoring a snapshot or cloning to a StorageClass of type Thick is now rejected - previously the result was Bound PVC without data
• Correction: free space check for Thick is done by aligned size, error of selecting node with maximum free space is no longer ignored
• Updating base images and lib-helm to 1.72.12
• Fixed vulnerability in gRPC (GHSA-hrxh-6v49-42gf)
• Internal changes in module assembly

v0.4.11

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

v0.4.10

• Added the ability to select LVMVolumeGroup by labels (labelSelector) in LocalStorageClass
• Internal changes in module assembly

v0.4.9

• Fixed generation of access secret to registry (deckhouse-registry): Now it only contains authorization data for the active image source
• Updating container-base images to v1.1.8, Go 1.26.4 and lib-helm to 1.72.4

v0.4.8

• Updating container-base images to v1.1.2

v0.4.7

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

v0.4.6

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

v0.4.5

• Internal changes in module structure and assembly

v0.4.4

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

v0.4.3

• Corrections to the module structure

v0.4.2

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

v0.4.1

• Updating base images and lib-helm

v0.4.0

• CVE fixes
• Transition to a common scheduler for SDS
• Replacing a fixed resize delta with automatic determination of the LVM partition size delta

v0.3.19

• Added a hook for clearing resources when the module is turned off
• Removed the enableThinProvisioning setting, we assume that thin provisioning is always enabled
• Module-sdk update for CVE fix, golang update

v0.3.18

• Module-sdk update for CVE fix
• Removed the enableThinProvisioning setting, we assume that thin provisioning is always enabled

v0.3.17

• Fix controller panic when processing LVG without Node in status
• Reworking manifests, combining controller and webhook into one Pod

v0.3.16

• Documentation fixes
• Fixes in scheduler, corrected behavior when working with other provisioners
• Bug fixes in controller

v0.3.15

• Fix HA-mode, now it works correctly
• Removed scheduler functionality, remaining for compatibility with old Deckhouse versions

v0.3.14

• Updated base images versions
• CVE fix
• Updated Go to 1.24.10

v0.3.13

• Updated Go version to 1.24.9
• Updated lib-helm to deckhouse_lib_helm-1.64.1
• Documenation updates
• Module refactoring

v0.3.12

• Updated Go version to 1.24.8
• Updated lib-helm to deckhouse_lib_helm-1.63.6

v0.3.11

• Added release notes
• Hooks switched from python to golang

v0.3.10

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

v0.3.9

• CVE fixes

v0.3.8

• CVE fixes
• Internal changes for containerd v2 support
• Added dependency on snapshot-controller

v0.3.7

• Added NodeGetVolumeStats method (for kubelet_volume_stats_* metrics support)

v0.3.6

• Documentation fixes

v0.3.5

• Several fixes for proper VolumeSnapshots support

v0.3.4

• Completely fixed the issue with enabled csi snapshotter in CE version

v0.3.3

• Fixed the issue with enabled csi snapshotter in CE version
• Enabled HA mode in CSI controller

v0.3.2

• Technical release, module refactoring

v0.3.1

• Documentation fixes
• Module refactoring

v0.2.3

• Technical release. Removed “Preview” status from documentation

v0.2.1

• Fixed issue where freed PVC could be considered as used
• Reduced module size, excluded build images

v0.2.0

• Updated golang API libraries for sds-node-configurator v0.4.0 support
• Multiple fixes in controllers and documentation
• Added XFS filesystem support

v0.1.2

• Removed isDefault field (use standard k8s SC annotation)
• Added support for contiguous volumes
• Added antiaffinity rules for controller HA mode
• Added AllocationLimit support
• Added health and readiness checks in controller

v0.1.1

• Added documentation description of sds-local-volume pod management process

v0.1.0

• Fix max volumes per node and R/W map
• Add LocalStorageClass validation webhook
• Add logs and upgrading node scoring
• Add module documentation
• Add cache for extender-scheduler
• Add previous channel release version check
• Fix KubeSchedulerConfiguration API version