Aaryan123456679 commented on code in PR #70238:
URL: https://github.com/apache/airflow/pull/70238#discussion_r3635540809
##########
chart/values.schema.json:
##########
@@ -104,7 +104,7 @@
"pod": {
"description": "Default pod security context definition.
The values in this parameter will be used when `securityContexts` is not
defined for specific Pods.",
"type": "object",
- "$ref":
"#/definitions/io.k8s.api.core.v1.PodSecurityContext",
+ "$ref": "#/definitions/AirflowPodSecurityContext",
Review Comment:
The `default` here doesn't relax the type constraint — it's just
documentation for tooling/UI, not a JSON Schema validation rule.
The actual problem is that the vendored
`io.k8s.api.core.v1.PodSecurityContext` definition types
`runAsUser`/`runAsGroup`/`fsGroup` as `"type": "integer"` only (non-nullable).
So even with `default: {}` at the parent `pod` object, a user who explicitly
sets `securityContexts.pod.runAsUser: null` in their own values file (exactly
what's needed for OpenShift, since SCC assigns the UID/GID automatically) fails
schema validation before the templates ever render.
We can't just relax the vendored definition in place, because
`vendor_k8s_json_schema.py` regenerates every `io.k8s.*`-prefixed definition
from the upstream Kubernetes OpenAPI spec — a hand edit there would be silently
reverted on the next regen. That's why this introduces
`AirflowPodSecurityContext`: identical to the vendored definition, except
`runAsUser`/`runAsGroup`/`fsGroup` allow `["integer", "null"]`, and it's named
outside the `io.k8s.*` namespace so it's untouched by regeneration.
Happy to adjust the approach if there's a lighter-weight way to express this
that I'm missing — let me know if you had something else in mind.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
