Problem
spec.serverConfigRollHash on ValkeyNode is an internal implementation detail used to trigger pod rolls when the server config changes. It is set by the ValkeyCluster controller and was never intended to be part of the public CRD API.
Exposing it in the spec means it appears in kubectl describe, helm templates, and any tooling that introspects the CRD schema. This leaks implementation detail, confuses users, and creates an accidental API contract.
This was noted as a limitation in PR #209.
Proposed fix
Move the config hash into an annotation on the ValkeyNode (or on the managed StatefulSet's pod template) rather than a spec field. The ValkeyCluster controller writes the annotation; the ValkeyNode controller reads it to determine whether a roll is needed.
This removes serverConfigRollHash from the CRD spec entirely. The change must be backwards-compatible (existing clusters must not trigger spurious rolls on upgrade).
Acceptance criteria
References
Related GitHub issues (live configuration)
Roll triggers and “what must go through CONFIG SET vs a pod restart” are the same product surface. These issues are the open live config workstream:
Sequencing note: Moving serverConfigRollHash off the public spec (e.g. to an annotation) can stay a small API cleanup if roll semantics stay unchanged. If you instead want one coherent “config propagation” design (live apply + roll fallback + no leaked internals), treat this as part of the same design pass as #210–#212 and coordinate there.
Problem
spec.serverConfigRollHashonValkeyNodeis an internal implementation detail used to trigger pod rolls when the server config changes. It is set by theValkeyClustercontroller and was never intended to be part of the public CRD API.Exposing it in the spec means it appears in
kubectl describe,helmtemplates, and any tooling that introspects the CRD schema. This leaks implementation detail, confuses users, and creates an accidental API contract.This was noted as a limitation in PR #209.
Proposed fix
Move the config hash into an annotation on the ValkeyNode (or on the managed StatefulSet's pod template) rather than a spec field. The
ValkeyClustercontroller writes the annotation; theValkeyNodecontroller reads it to determine whether a roll is needed.This removes
serverConfigRollHashfrom the CRD spec entirely. The change must be backwards-compatible (existing clusters must not trigger spurious rolls on upgrade).Acceptance criteria
serverConfigRollHashremoved fromValkeyNodespecValkeyNodeCRD schema updated; migration note added to release notesReferences
Related GitHub issues (live configuration)
Roll triggers and “what must go through
CONFIG SETvs a pod restart” are the same product surface. These issues are the open live config workstream:Sequencing note: Moving
serverConfigRollHashoff the public spec (e.g. to an annotation) can stay a small API cleanup if roll semantics stay unchanged. If you instead want one coherent “config propagation” design (live apply + roll fallback + no leaked internals), treat this as part of the same design pass as #210–#212 and coordinate there.