1fanwang commented on issue #70953: URL: https://github.com/apache/airflow/issues/70953#issuecomment-5188998524
Verified [Opt-in concurrent pod creation in KubernetesExecutor](https://github.com/apache/airflow/pull/68480) on `cncf-kubernetes 10.21.0rc1`. Minor issue - The behavior is correct, but the RC ships a wrong `versionadded` on both new config options, which is my mistake. Details at the bottom. I do not think it blocks the release, see https://github.com/apache/airflow/pull/71157. Airflow 3.3.0, two identical virtualenvs: one with the RC providers, one with the previous stable release. This is scheduler-loop code, so it is not a Dag run. Instead the real `KubernetesExecutor.sync()` is driven with 12 jobs on its real task queue, with the Kubernetes API stubbed at a fixed 0.25s per create call so the concurrency is measurable. ```bash # cncf-kubernetes 10.21.0rc1, flag on and off .venv/bin/python k8s_executor_e2e.py true .venv/bin/python k8s_executor_e2e.py false # cncf-kubernetes 10.20.0 .venv-prev/bin/python k8s_executor_e2e.py true ``` ``` # cncf-kubernetes 10.21.0rc1, async_pod_creation=True async_pod_creation=True pod_creation_max_concurrency=12 QUEUED_PODS=12 latency_per_create=0.25s PODS_CREATED=12 WALL_CLOCK=0.26s FIRST_TO_LAST_CREATE_START=0.00s SEQUENTIAL_WOULD_COST=3.00s # cncf-kubernetes 10.21.0rc1, async_pod_creation=False (the default) async_pod_creation=False PODS_CREATED=12 WALL_CLOCK=3.09s FIRST_TO_LAST_CREATE_START=2.84s # cncf-kubernetes 10.20.0, the code path does not exist AttributeError: <class '...AirflowKubernetesScheduler'> does not have the attribute '_build_pod_request' ``` All 12 creates start within 0.00s of each other when the flag is on. With it off the RC matches the old sequential timing, so the default is unchanged. ### Wrong `versionadded` on both new options `async_pod_creation` and `pod_creation_max_concurrency` both carry `version_added: 10.20.0`, but they ship in 10.21.0. Neither name appears anywhere in the released 10.20.0 wheel: ``` $ for opt in running_pod_log_lines async_pod_creation pod_creation_max_concurrency \ pod_launch_failure_retries pod_launch_failure_excluded_container_reasons; do printf "%-46s %s\n" "$opt" \ "$(grep -c "$opt" .venv-prev/.../cncf/kubernetes/get_provider_info.py)" done running_pod_log_lines 1 async_pod_creation 0 pod_creation_max_concurrency 0 pod_launch_failure_retries 2 pod_launch_failure_excluded_container_reasons 1 ``` Those are the five options in `provider.yaml` tagged `version_added: 10.20.0`. The other three are correct and really did ship in 10.20.0, so this is limited to the two I added. Still present on main at [provider.yaml#L378](https://github.com/apache/airflow/blob/44acf383e47892465c7e14f55f08b914ae150085/providers/cncf/kubernetes/provider.yaml#L378) and [#L389](https://github.com/apache/airflow/blob/44acf383e47892465c7e14f55f08b914ae150085/providers/cncf/kubernetes/provider.yaml#L389). The docs build turns this into a `.. versionadded:: 10.20.0` directive on the configuration reference page, so the published 10.21.0 page will tell a reader both options are available in 10.20.0. Someone on 10.19 who wants concurrent pod creation would upgrade to 10.20.0 and find nothing there. No runtime effect, since nothing reads `version_added` outside the docs build, so I would not hold the release for it. PR moving both to 10.21.0: https://github.com/apache/airflow/pull/71157 For what it is worth, the value was right when PR was wrote. 10.19.0 was the latest release when the PR was opened on 2026-06-12, so 10.20.0 was the next version. 10.20.0 was then cut on 2026-07-23 while the PR was still in review, and it merged six days later. Nothing revalidates the field after that: the schema accepts any string, should we maybe add a pre-commit / breeze check compares it against the version being released. Any config-option PR that stays open across a release boundary can pick this up. -- 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]
