Apply KubernetesPodOperator template fields only after rendering - #71174
Draft
rjgoyln wants to merge 1 commit into
Draft
Apply KubernetesPodOperator template fields only after rendering#71174rjgoyln wants to merge 1 commit into
rjgoyln wants to merge 1 commit into
Conversation
Template fields are rendered after the constructor runs, so converting or merging their values there operates on the un-rendered Jinja expression: a templated base_container_name never reached the container_logs fallback, a templated configmaps string was iterated character by character, and templated volumes were rejected at Dag parse time. Clears the KubernetesPodOperator entry of the burn-down tracked at apache#70296.
rjgoyln
force-pushed
the
fix-kpo-template-field-init
branch
from
August 5, 2026 15:47
36f2991 to
0253bf6
Compare
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
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
KubernetesPodOperatorconverted and merged several template-field values in__init__, which runs before Jinja rendering. A templatedbase_container_namewas copied into the defaultcontainer_logsand never rendered, so log fetching asked for a container that did not exist. A templatedconfigmapsstring was iterated character by character intoenv_from, and templatedvolumes/volume_mountswere rejected at Dag parse time before they could resolve.__init__now only stores these arguments; the conversions run inbuild_pod_request_obj()andcontainer_logsresolves its base-container fallback lazily.configmapsbecomes a declared template field, having previously been rendered by accident through theenv_fromlist it was merged into.An
env_varsmapping is the one conversion that still precedes rendering, in arender_template_fieldsoverride: an env var name is a template field ofV1EnvVar, while a plain dict renders only its values. Only the container shape is inspected, never the value.Behavior change
SparkKubernetesOperatorno longer warns thatcontainer_logs"is not supported and will be overridden" when the user never passed it; an explicitly requested container is still overridden to the driver container.Clears the
KubernetesPodOperatorentry of the burn-down tracked in #70296.Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 5) following the guidelines