Skip to content

feat(storagecluster): add spec.checkSumValidation for inline CRC checksum validation - #434

Draft
boddumanohar wants to merge 8 commits into
mainfrom
feat/checksum-validation
Draft

feat(storagecluster): add spec.checkSumValidation for inline CRC checksum validation#434
boddumanohar wants to merge 8 commits into
mainfrom
feat/checksum-validation

Conversation

@boddumanohar

@boddumanohar boddumanohar commented Aug 17, 2026

Copy link
Copy Markdown
Member

fixes: #433

Summary

Adds StorageCluster.spec.checkSumValidation to expose sbcli's inline CRC checksum validation feature (silent-data-error protection, design ref TD.100226.1) through the operator.

apiVersion: storage.simplyblock.io/v1alpha1
kind: StorageCluster
spec:
  checkSumValidation:
    inlineChecksum: true
    atomic4k: true
  • inlineChecksum (*bool, default false) — enables inline CRC checksum validation on every IO.
  • atomic4k (*bool, default false) — only meaningful when inlineChecksum is true; declares 4K write atomicity on devices with a <4K logical block size (e.g. AWS NVMe).
  • The whole checkSumValidation struct is immutable once set (CEL XValidation equality rule + +k8s:immutable), matching the backend: the checksum method is baked into each device's bdev_alceml_create call once, at cluster-create time, and never re-applied.
  • Wired into ClusterAddParamsPOST /api/v2/clusters/, following the same pattern as enableFailureDomains.
  • A new validating webhook (StorageClusterValidator, /validate-storage-simplyblock-io-v1alpha1-storagecluster) rejects atomic4k: true without inlineChecksum: true — that combination configures nothing on the backend and would just mislead readers of the CR.

Blocked on

Test plan

  • make generate / make manifests regenerated deepcopy, CRD manifests, and the new ValidatingWebhookConfiguration entry
  • 2 new controller tests: checkSumValidation fields make it into the POST /api/v2/clusters/ payload when set, and are omitted from the payload when unset
  • 6 new webhook tests covering the atomic4k requires inlineChecksum rule (unset, both false, inlineChecksum alone, both true, atomic4k alone, atomic4k with nil inlineChecksum)
  • Full repo build, vet, and test suite pass
  • End-to-end verification against a live cluster once sbcli#1250 lands (no per-pool/per-lvol equivalent exists or is planned — this is cluster-level only, matching the backend design)

🤖 Generated with Claude Code

…ksum validation

Adds StorageCluster.spec.checkSumValidation.{inlineChecksum,atomic4k}, mirroring
sbcli's cluster-level inline_checksum/atomic_4k fields (design ref TD.100226.1).
Both are frozen at cluster-create time on the backend, so the whole struct is
marked immutable (kubebuilder XValidation equality rule + k8s:immutable), same
pattern as enableFailureDomains.

Requires the corresponding sbcli backend support (simplyblock/sbcli#1250) on
POST /api/v2/clusters/ -- against an unpatched backend, setting these fields
is a silent no-op since the field is simply unread by the API.
…Cluster

atomic4k only has meaning as an inline-checksum fallback-path escape hatch
(tells the data plane to skip its own >=4K block-size gate for devices like
AWS NVMe); with checksum validation off it configures nothing on the backend
and just misleads readers of the CR. Both fields are already immutable once
checkSumValidation is set (CEL rule on StorageClusterSpec), so the webhook
only needs to catch the combination at create/first-set time.
…fix gocyclo

- make helm-sync: propagate the new checkSumValidation CRD field and
  storagecluster validating webhook into the Helm chart.
- make build-installer: regenerate dist/install.yaml with the same.
- Split the two new checksum-validation subtests out of
  TestStorageClusterReconcileCreationPaths into their own test function --
  the combined table pushed that function's cyclomatic complexity over
  golangci-lint's gocyclo limit (35 > 30).
Wires StorageNodeSet.spec.enableTestDevice through to the /storage-nodes
add-node payload as enable_test_device, letting a node's devices get a
passtest bdev inserted below alceml for fault injection (see
sbcli sn device-testing-mode, e.g. corrupt_data_on_write -- used by
TestChecksumCorruptionDetection to prove inline checksum validation
actually detects corruption).

No production safeguard yet: unlike enable_hang_device (never exposed via
any operator CRD), this field is left in the schema as-is for now so
k8s-native e2e can exercise it. Restricting it (e.g. an admission webhook
allow-listing a test-runner ServiceAccount, mirroring StorageNodeValidator's
spec.workerNode gate) is tracked as a followup before this should be
considered safe for production clusters.
…ot enable_test_device

The v2 storage-node REST API's StorageNodeParams field is `test_device`
(simplyblock_web/api/v2/cluster/storage_node/__init__.py); `enable_test_device`
is only the internal storage_node_ops.add_node() kwarg name it maps to
server-side. Sending `enable_test_device` on the wire was silently dropped
as an unrecognized field -- verified live: no passtest bdev was created
despite spec.enableTestDevice: true.
…evice, not enable_test_device"

This reverts commit e3c567e.
@boddumanohar
boddumanohar force-pushed the feat/checksum-validation branch from e06fbe4 to d9dfde1 Compare August 21, 2026 12:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support enabling/disabling inline checksum validation (CRC) on StorageCluster

2 participants