Repository navigation
feat: Declare the probe and security context defaults in the CRD schema - #72
Merged
Merged
Conversation
The readiness probe timings and the pod identity were defaulted only by the
builders, so a stored MemgraphCluster never showed the values its pods ran
with. Both are now CRD schema defaults, mirrored by Go constants for specs
that never passed admission, like every other default:
- readinessProbe defaults to {} and each timing to 20/10/5, so a timing left
out beside a written one is filled in too.
- securityContext, when absent, defaults to runAsUser 101, runAsGroup 103,
fsGroup 103, the values the builder already wrote. No field inside the
block has a default, so an empty block still leaves all three to the
platform, as OpenShift's restricted-v2 needs.
Pods are unchanged. The uploader's image, already required by the schema,
now says so with +required like every other field.
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
1 participant
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.
Why
Following the Kubernetes API convention that defaults should be visible in the object rather than implied ("unspecified fields get the default behavior"), two defaults existed only in the builders. A stored
MemgraphClusternever showed the readiness probe timings or the uid/gid its pods ran with.What
readinessProbe:default={}on the block, and20/10/5onfailureThreshold/timeoutSeconds/periodSeconds. A timing left out beside a written one is now filled in too.securityContext: when absent, it defaults to{runAsUser: 101, runAsGroup: 103, fsGroup: 103}, the valuesnormalizeSecurityContextalready wrote. No field inside the block has a default, sosecurityContext: {}still leaves all three to the platform (OpenShiftrestricted-v2). The constants move to the API package asDefaultRunAsUser/DefaultRunAsGroup/DefaultFSGroup. The builder fallback stays, like every other default, for specs that never passed admission.coreDumps.uploader.imagegets an explicit+required. It was already required, because its json tag has noomitempty. The CRD is otherwise unchanged by this line, and every field in the API now carries an explicit marker.version1.0.1-rc.1 → 1.0.1-rc.2 (the chart's CRD changed).appVersionis unchanged.Pod templates don't change, so nothing restarts. Existing objects pick up the defaults when the API server reads them.
Testing
make test(the envtest defaults test now expects both blocks to be filled in, and an emptysecurityContextstill round-trips empty),make lint,make chart-verify,make helm-lint,make chart-version-check.