fix: strip enabled key from securityContext before rendering#166
Open
DarpaSehgal wants to merge 2 commits into
Open
fix: strip enabled key from securityContext before rendering#166DarpaSehgal wants to merge 2 commits into
DarpaSehgal wants to merge 2 commits into
Conversation
The podSecurityContext, securityContext, and metrics exporter securityContext values support an 'enabled' field as a helm-level toggle. However, this field is not a valid Kubernetes PodSecurityContext or SecurityContext field. When rendered verbatim, Kubernetes silently strips it, causing GitOps tools like ArgoCD and Rancher Fleet to report resources as perpetually out-of-sync. Use omit to strip the 'enabled' key before piping to toYaml in both deploy_valkey.yaml and statefulset.yaml templates. Fixes: valkey-io#139 Signed-off-by: Darpa Sehgal <6688157+DarpaSehgal@users.noreply.github.com>
DarpaSehgal
force-pushed
the
fix/omit-enabled-from-securitycontext
branch
from
db3bcd7 to
27e465c
Compare
Collaborator
|
Thanks @DarpaSehgal, that would close #139. Can you please add a test case? |
Add helm-unittest cases for all four securityContext locations (pod, init container, main container, metrics exporter) in both deploy_valkey.yaml and statefulset.yaml templates. Each test sets enabled: true alongside valid fields and asserts that enabled does not appear in the rendered output while the other fields render correctly. Signed-off-by: Darpa Sehgal <6688157+DarpaSehgal@users.noreply.github.com>
DarpaSehgal
force-pushed
the
fix/omit-enabled-from-securitycontext
branch
from
8c20789 to
8f26c1a
Compare
Author
|
Added test cases covering all four Each test:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
podSecurityContextandsecurityContextvalues support anenabledfield as a helm-level toggle (common in Bitnami-style charts). However,enabledis not a valid Kubernetes PodSecurityContext or SecurityContext field. When rendered verbatim into the manifest, Kubernetes silently strips it on storage, causing the actual stored state to differ from what Helm rendered. This breaks drift detection in GitOps tools (ArgoCD, Rancher Fleet, etc.), reporting resources as perpetually out-of-sync.Changes
Used
omitto strip theenabledkey before piping totoYamlin all security context rendering locations across both templates:valkey/templates/deploy_valkey.yaml(4 spots: pod, init container, main container, metrics exporter)valkey/templates/statefulset.yaml(4 spots: same)Testing
Render the chart with
podSecurityContext.enabled=trueand verifyenableddoes not appear in the output YAML: