uplsh580 commented on code in PR #61039:
URL: https://github.com/apache/airflow/pull/61039#discussion_r2875126858
##########
chart/values.yaml:
##########
@@ -2309,6 +2309,39 @@ dagProcessor:
# classpath: "airflow.dag_processing.bundles.local.LocalDagBundle"
# kwargs: {}
+ # Per-bundle deployment option
+ # When enabled, creates a separate deployment for each bundle in
`dagBundleConfigList`
+ deployPerBundle:
+ enabled: false
+ # Command args template for per-bundle deployments
+ # `{{ bundleName }}` will be replaced with the actual bundle name
+ args: ["bash", "-c", "exec airflow dag-processor --bundle-name {{
bundleName }}"]
Review Comment:
Thank you for pointing that out. To be honest, I also had concerns that
exposing args might add unnecessary complexity and potentially confuse users.
The reason I included it was primarily for consistency with the existing
single DAG processor configuration, which already allows overriding `args` in
the current Helm Chart. I wanted to ensure that the bundle-specific processors
followed the same pattern as the standard one, just in case users needed that
same level of flexibility.
https://github.com/apache/airflow/blob/fbf687cbb126b3547354179b02d99bfa105b0fe2/chart/values.yaml#L2383
To simplify this, I’d like to propose automating the argument injection
instead.
When `deployPerBundle` is enabled, the template can take the base args from
the global dagProcessor (e.g., `["bash", "-c", "exec airflow dag-processor"]`)
and automatically append the `--bundle-name {{ bundleName }}` flag for each
specific deployment.
However, I am a bit cautious about this approach because I am not fully
aware of all the different ways users might be overriding the default args. If
a user has a very complex custom command, simply appending a flag at the end
might not work in every scenario.
--
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]
