Skip to content

refactor(tolerations): drop the DRBD taint tolerations - #211

Merged
duckhawk merged 2 commits into
mainfrom
refactor/drop-drbd-tolerations
Aug 23, 2026
Merged

refactor(tolerations): drop the DRBD taint tolerations#211
duckhawk merged 2 commits into
mainfrom
refactor/drop-drbd-tolerations

Conversation

@duckhawk

@duckhawk duckhawk commented Aug 22, 2026

Copy link
Copy Markdown
Member

Description

Removes the DRBD taint tolerations from the storage-problems additional strategy in helm_lib_tolerations.

Three changes in _node_affinity.tpl:

  • The three drbd.linbit.com/{lost-quorum,force-io-error,ignore-fail-over} toleration keys are gone.
  • storage-problems is no longer added to $additionalStrategies by default, so it no longer applies to every base strategy except wildcard.
  • _helm_lib_additional_tolerations_storage_problems is kept as an empty, documented no-op. It is not dead code by accident — it is a compatibility shim, see below.

Why do we need it, and what problem does it solve?

storage-problems was enabled by default in every base strategy except wildcard, which means lib-helm put LINBIT-vendor-specific taint keys on essentially every workload rendered through the library — cloud providers, CNI, MetalLB, monitoring — regardless of whether the module has anything to do with block storage. A general-purpose Helm library should not carry one storage vendor's taint vocabulary in its default path.

More importantly, those tolerations are dead. Nothing applies the taints:

  • sds-replicated-volume does not taint nodes at all any more (grep -rniE '\btaint' over the module returns nothing) — the LINSTOR-era components that used to set drbd.linbit.com/* are gone.
  • No other module in the fleet references those keys. The only remaining hits across ourmodules/* are pasted YAML inside archived support threads.

So the change removes tolerations that could never match a taint.

What is the expected result?

Rendered output loses the three drbd.linbit.com entries; everything else is byte-identical. Concretely, any-node now renders:

tolerations:
- key: node-role.kubernetes.io/master
- key: node-role.kubernetes.io/control-plane
- key: node.deckhouse.io/etcd-arbiter
- key: dedicated.deckhouse.io
  operator: "Exists"
- key: dedicated
  operator: "Exists"
- key: DeletionCandidateOfClusterAutoscaler
- key: ToBeDeletedByClusterAutoscaler

Why the strategy name survives as a no-op. Four charts in deckhouse pass with-storage-problems explicitly:

  • modules/021-cni-cilium/templates/_agent-daemonset.tpl and .../safe-agent-updater/daemonset.yaml
  • ee/se-plus/modules/021-cni-cilium/templates/egress-gateway-agent/daemonset.yaml
  • ee/modules/380-metallb/templates/speaker/daemonset.yaml and ee/se/modules/380-metallb/templates/l2lb/speaker/daemonset.yaml

include of an undefined template is a hard render error, so deleting the definition outright would make those charts fail to render the moment Deckhouse picks up this version. That is not an acceptable failure mode for a patch release of a library, hence the shim: with-storage-problems and without-storage-problems keep working and simply produce nothing. Dropping the definition is a follow-up, after the call sites are cleaned up.

Two things reviewers of downstream repos should know:

  1. Deckhouse template_tests will need updating. Five modules assert exact toleration lists that include the DRBD keys and will fail once Deckhouse bumps lib-helm: cloud-provider-dynamix, cloud-provider-vcd, cloud-provider-openstack, cloud-provider-huaweicloud (ee/modules/030-*/template_tests/module_test.go) and cloud-provider-vsphere (ee/se-plus/modules/030-*). Test-only, no runtime effect.
  2. Three storage modules pass a malformed argument and were relying on the default: sds-node-configurator, sds-replicated-volume (agent and linstor-node) and storage-status call helm_lib_tolerations with a bare "storage-problems", without the with-/without- prefix the parser requires. That argument has always been silently ignored — they got the tolerations from the default, not from their own request. They lose them now, with no runtime consequence since no taint producer exists, but the bare argument is worth removing when those charts are next touched.

Covered by a new suite, helm_lib_tolerations_base_strategy_test.yaml, with three cases: a base strategy renders no DRBD keys, with-storage-problems still renders, and without-storage-problems is still accepted. Verified to fail against main's template and pass against this one. helm unittest ./tests/ — 361 passed, 84 suites. go run tools/build-doc.go --diff clean.

Chart version bumped to 1.72.17. 1.72.15 is taken by #209 and 1.72.16 by #210, so all three can merge in any order.

Checklist

  • The code is covered by unit tests.
  • e2e tests passed.
  • Documentation updated according to the changes.
  • Changes were tested in the Kubernetes cluster manually.

The "storage-problems" additional strategy tolerated three
drbd.linbit.com taints — lost-quorum, force-io-error and
ignore-fail-over — and it was applied by default to every base
strategy except "wildcard". That put LINBIT-specific keys on
essentially every workload rendered through lib-helm, including
modules that have nothing to do with block storage.

Nothing sets those taints anymore: the LINSTOR-based stack that used
to apply them is gone from sds-replicated-volume, and no module in the
fleet taints nodes with them. The tolerations are dead weight.

Remove the keys and stop applying the strategy by default. The
strategy name itself stays as a no-op so that the existing
"with-storage-problems" and "without-storage-problems" call sites keep
rendering; it can be dropped once those are cleaned up.

Signed-off-by: v.oleynikov <vasily.oleynikov@flant.com>
@NikolayDemchuk
NikolayDemchuk self-requested a review August 23, 2026 15:25
Signed-off-by: Vasily Oleynikov <vasily.oleynikov@flant.com>
@duckhawk
duckhawk merged commit 6625f40 into main Aug 23, 2026
4 checks passed
@duckhawk
duckhawk deleted the refactor/drop-drbd-tolerations branch August 23, 2026 15:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants