Release Notes

v0.0.5

Release date: 2026-09-02

ElasticCluster networks are described as lists of CIDRs (a breaking change of the resource schema, migrated automatically), an ElasticStorageClass can reserve a share of the filesystem for the superuser, and release notes carry sections instead of one flat list.

Highlights

Changes in this release:

• ElasticCluster.spec.network.public and .cluster accept several CIDRs, so a Ceph cluster whose storage nodes sit in more than one host subnet can be described. Both fields are lists now, which is a breaking change of the resource schema; existing resources are migrated on upgrade.
• An ElasticStorageClass 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 are formatted with no reserve unless it is asked for.
• A release now has a summary and per-kind sections — new features, improvements, fixes, security, breaking changes, upgrade notes — on the module’s release-notes page and in ModuleRelease.spec.changelog, where the Deckhouse console renders it.

New features

This release adds:

• ElasticCluster.spec.network.public and .cluster take one or more CIDRs each, which is what a cluster whose storage nodes span several host subnets needs: every Ceph daemon binds to a host interface and has to own an address inside one of the given ranges.
• storage.deckhouse.io/ext4-reserved-percent on an ElasticStorageClass sets the percentage of a volume kept for the superuser: a whole number from 0 to 50, default 0. The module copies the resolved value onto the CephStorageClass it generates, so clearing the annotation returns the class to the default. It applies to volumes created afterwards — an existing filesystem keeps the reserve it was created with — and only to type: RBD, because a CephFS volume is a subdirectory of an existing filesystem and is never formatted. An invalid value leaves the ElasticStorageClass with its storage-class stage failing and the reason in its status, instead of breaking volume creation later.

Improvements

This release improves:

• An ElasticCluster whose spec.storage.nodeSelector selects nodes that the module setting settings.dataNodes.nodeSelector excludes now says so: the StorageReady condition names the nodes that carry no sds-node-configurator agent and the setting to widen, instead of reporting that no BlockDevice matches the selectors. A selector that matches no node at all is reported separately from an empty BlockDevice set.
• 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, so the console shows the notes in the language of the reader.
• The release history before this version keeps the previous flat format and renders on the same page exactly as before; nothing had to be rewritten.

Fixes

This release fixes:

• 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.

Breaking changes

Changes that affect backward compatibility:

• ElasticCluster.spec.network.public and .cluster are lists of CIDRs, not single strings. A manifest kept for re-applying has to be updated to the list form; resources that already exist are migrated on upgrade.

Upgrade notes

Before upgrading, note the following:

• An ElasticCluster created before this version is migrated automatically on upgrade: each of spec.network.public and .cluster becomes a one-element list holding the same address. No daemon is restarted and nothing has to be done by hand.

Docs

Documentation changes:

• The section on reserving part of a volume for the superuser is new, with the annotation, its range and what it does not cover.
• The documentation of settings.dataNodes.nodeSelector now states what the data-node label actually controls — whether the sds-node-configurator agent runs on a node, and therefore whether that node has any BlockDevice — how it relates to ElasticCluster.spec.storage.nodeSelector, and that the empty default covers control-plane nodes too.

v0.0.4

• Fix: caBundle for webhooks is now sourced from the webhooks-https-certs secret, and the module’s service accounts are excluded from validation — a broken webhook no longer leaves ElasticCluster without a status and Ceph undeployed
• Fix: a fresh cluster no longer enters HEALTH_WARN RECENT_MGR_MODULE_CRASH — mgr modules that cannot load (dashboard, restful, cephadm, diskprediction_local, rook) have been removed from the image
• Controller metrics are now published via kube-rbac-proxy and collected by a ServiceMonitor
• The module has been migrated to the common logger; the logging level is taken from the module settings, as documented
• Fix: rebuilding the same tag no longer leaves an outdated changelog in the release image
• Base images updated to v2.1.7, Go to 1.27.0, and lib-helm to 1.72.18
• Internal changes to the module build and e2e tests

v0.0.3

• Build changes

v0.0.2

• Added the ability to control Rook object-store CRs from the sds-object controller (webhooks)
• ElasticClusterCredential publishes status.conditions with the Ready condition; the status is generated through the common conditions library, status.conditions in the CRD is declared as a keyed list for the correct server-side apply
• Fix: VPA gate for the presence of a CRD, and not for the list of enabled modules
• Fix: The Ceph cluster no longer goes into HEALTH_WARN - the non-working mgr module restful has been disabled, a dependency has been added to load the telemetry mgr module
• Build Ceph images moved to container-base + pm; supported versions - 19.2.5 (squid) and 20.2.3 (tentacle)
• Documentation clarified: spec.network.public/cluster should be host subnets
• Update base images to v2.1.2, Go to 1.26.6 and lib-helm to 1.72.14
• Internal changes in module assembly

v0.0.1

• Initial release of the module
• Added module setting settings.dataNodes.nodeSelector. The controller places the label storage.deckhouse.io/sds-elastic-node="" on each Kubernetes node that matches the selector and removes the label from nodes that no longer match it. Downstream components (sds-node-configurator agent, ElasticCluster hosting) can use this label as nodeAffinity (pod-node affinity rule) to select data nodes.