User Story
As an operator installing the OpenShell Helm chart with podSecurityContext: null
(e.g. to let OpenShift's SCC assign the UID/GID range), I want the gateway
workload template to omit the securityContext: block entirely, so that the
manifest is valid and the gateway deploys.
Problem Statement
deploy/helm/openshell/templates/_gateway-workload.tpl renders the pod-level
security context unconditionally:
securityContext:
{{- toYaml .Values.podSecurityContext | nindent 4 }}
When podSecurityContext is null, toYaml emits null, producing
securityContext: null instead of omitting the field. On OpenShift, clearing
podSecurityContext is the normal way to defer UID/GID assignment to the
restricted-v2 SCC, so this path is hit in practice.
Impact / Why This Matters
Operators who null out podSecurityContext to be SCC-compatible get an invalid
or misleading rendered manifest rather than a clean omission. The workaround is
to override the whole securityContext sub-tree by hand, which defeats the point
of setting it to null. This is independent of the e2e harness (#2956) and affects
production installs.
Reproduction Steps
helm template openshell deploy/helm/openshell --set podSecurityContext=null
- Inspect the gateway Deployment/StatefulSet: the pod spec renders
securityContext: null instead of omitting it.
Environment
- Chart:
deploy/helm/openshell
- Template:
templates/_gateway-workload.tpl
- Any Helm 3.x; observed while enabling OpenShift SCC compatibility.
Acceptance Criteria
Fixed by #3034, a dedicated PR scoped to this chart bug.
The OpenShift e2e branch (#2956) also carries a copy of the same one-line fix so
it stays runnable in the meantime; once #3034 merges, that branch will rebase and
the duplicate hunk drops out.
User Story
As an operator installing the OpenShell Helm chart with
podSecurityContext: null(e.g. to let OpenShift's SCC assign the UID/GID range), I want the gateway
workload template to omit the
securityContext:block entirely, so that themanifest is valid and the gateway deploys.
Problem Statement
deploy/helm/openshell/templates/_gateway-workload.tplrenders the pod-levelsecurity context unconditionally:
When
podSecurityContextisnull,toYamlemitsnull, producingsecurityContext: nullinstead of omitting the field. On OpenShift, clearingpodSecurityContextis the normal way to defer UID/GID assignment to therestricted-v2SCC, so this path is hit in practice.Impact / Why This Matters
Operators who null out
podSecurityContextto be SCC-compatible get an invalidor misleading rendered manifest rather than a clean omission. The workaround is
to override the whole
securityContextsub-tree by hand, which defeats the pointof setting it to null. This is independent of the e2e harness (#2956) and affects
production installs.
Reproduction Steps
helm template openshell deploy/helm/openshell --set podSecurityContext=nullsecurityContext: nullinstead of omitting it.Environment
deploy/helm/openshelltemplates/_gateway-workload.tplAcceptance Criteria
podSecurityContext: null, the rendered pod spec omits thesecurityContext:block entirelypodSecurityContextset, the block renders unchanged (no regression){{- with .Values.podSecurityContext }}guardFixed by #3034, a dedicated PR scoped to this chart bug.
The OpenShift e2e branch (#2956) also carries a copy of the same one-line fix so
it stays runnable in the meantime; once #3034 merges, that branch will rebase and
the duplicate hunk drops out.