younsl opened a new pull request, #71942:
URL: https://github.com/apache/airflow/pull/71942

   ## What
   
   Add a top level extraObjects list to the [Airflow Helm 
chart](https://airflow.apache.org/docs/helm-chart/stable/index.html). Every 
item of the list is rendered as an additional manifest by the chart itself, by 
a new template file, chart/templates/extra-objects.yaml.
   
   Each item is either a mapping holding a full manifest, or a string holding a 
rendered manifest. Both forms go through the Helm [tpl 
function](https://helm.sh/docs/howto/charts_tips_and_tricks/#using-the-tpl-function),
 so chart values, .Release and .Chart are available inside them:
   
       extraObjects:
         - apiVersion: networking.k8s.io/v1
           kind: NetworkPolicy
           metadata:
             name: '{{ .Release.Name }}-deny-egress'
           spec:
             podSelector:
               matchLabels:
                 release: '{{ .Release.Name }}'
             policyTypes:
               - Egress
         - |
           apiVersion: v1
           kind: ConfigMap
           metadata:
             name: {{ .Release.Name }}-extra-config
           data:
             MY_KEY: "my_value"
   
   The default is an empty list, so nothing changes for existing users: with 
default values the template renders no object.
   
   ## Why
   
   The chart already provisions extra objects of two specific kinds, 
extraSecrets and extraConfigMaps (see the [parameters 
reference](https://airflow.apache.org/docs/helm-chart/stable/parameters-ref.html#kubernetes)),
 but there is no way to ship any other Kubernetes resource with the release.
   
   Today the documented answer is [Extending the 
Chart](https://airflow.apache.org/docs/helm-chart/stable/extending-the-chart.html):
 create a custom chart, add Airflow as a 
[subchart](https://helm.sh/docs/chart_template_guide/subcharts_and_globals/), 
run helm dependency build, and keep that wrapper in sync with the Airflow chart 
version. That is the right shape when the extra templates are a project of 
their own. It is a lot of machinery for one NetworkPolicy, one CRD instance 
from an operator the cluster already runs, or one ConfigMap consumed by 
something other than an Airflow container. The alternative is applying the 
resource out of band, which splits one deployment into two delivery paths and 
two lifecycles.
   
   With extraObjects those resources live in the same values file and the same 
[Helm release](https://helm.sh/docs/intro/using_helm/#three-big-concepts), so 
they are created, upgraded and removed with it.
   
   ## Prior art in other community charts
   
   This value is close to a de facto standard in widely used charts, which is 
also why extraObjects was picked as the name rather than a new one:
   
   | Chart | Value | Item forms |
   | --- | --- | --- |
   | [Argo 
CD](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/values.yaml) 
| extraObjects | mapping |
   | [External Secrets 
Operator](https://github.com/external-secrets/external-secrets/blob/main/deploy/charts/external-secrets/values.yaml)
 | extraObjects | mapping |
   | 
[Traefik](https://github.com/traefik/traefik-helm-chart/blob/master/traefik/templates/extra-objects.yaml)
 | extraObjects | mapping or string |
   | 
[kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/blob/main/charts/kube-prometheus-stack/values.yaml)
 | extraManifests | mapping or string |
   
   Accepting both a mapping and a string follows 
[traefik.render](https://github.com/traefik/traefik-helm-chart/blob/master/traefik/templates/_helpers.tpl)
 in the Traefik chart, which branches on typeIs "string" for exactly this 
reason: a mapping keeps the value schema validated and readable, while a string 
lets a whole manifest be generated by a template expression, which is the same 
trick the chart already relies on for the data field of extraSecrets and 
extraConfigMaps.
   
   ## Deliberate design choices
   
   * No chart metadata is injected. The chart adds no labels, no annotations 
and no [Helm hooks](https://helm.sh/docs/topics/charts_hooks/) to these 
manifests, unlike extraSecrets and extraConfigMaps. An extra object is exactly 
what the user declared, which keeps the value usable for resources whose labels 
are meaningful to a controller. The trade off is stated in the docs.
   * No new validation. Items are typed as object or string in 
[values.schema.json](https://github.com/apache/airflow/blob/main/chart/values.schema.json),
 and correctness of the manifest itself is left to the API server.
   * Documentation is added to the existing Extending the Chart page rather 
than a new page, so the umbrella chart approach and this lighter one are 
compared side by side, with a note pointing back to extraSecrets, 
extraConfigMaps and the extra container values where those are the better fit.
   
   ## On the chart versus Kustomize overlay decision
   
   Following the decision tree in 
[contributing-docs/29_helm_chart_development.rst](https://github.com/apache/airflow/blob/main/contributing-docs/29_helm_chart_development.rst),
 extraObjects is not a component: it adds no image, no controller, no CRD and 
nothing with an external owner, and it introduces no second path to an existing 
setting. It is a generic escape hatch, so it does not compete with the 
overlays. My reading is that it supports the direction the overlays take, 
because a user who needs a resource the chart deliberately does not model can 
carry it in their own values instead of asking for it to be modelled in the 
chart. Happy to move this to a discussion on the dev list first if maintainers 
see it differently.
   
   ## Tests
   
   New tests in chart/tests/helm_tests/other/test_extra_objects.py cover the 
default empty list, the mapping form, the string form, and several items of 
mixed form rendered in one release, asserting on the rendered objects and on 
templating of .Release.Name and .Release.Namespace.
   
   One change outside the new files: validate_k8s_object in 
chart/tests/chart_utils/helm_template_generator.py assumed metadata.labels is 
always set, which held only because every chart rendered object carries labels. 
User supplied objects need not, so the labels lookup now uses the "or {}" 
fallback already used in test_basic_helm_chart.py.
   
   Verified locally: the five tests above plus test_chart_quality.py pass, helm 
lint is clean, and the values schema hooks 
(sort_helm_values_schema_file_type_field.py, 
update_helm_schema_schema_type_fields_match.py, chart_schema.py, 
lint_json_schema.py) are applied, which accounts for the generated change in 
values_schema.schema.json.
   
   A newsfragment will be added in a follow up commit now that the PR number is 
known.
   
   ---
   
   ##### Was generative AI tooling used to co-author this PR?
   
   - [X] Yes (please specify the tool below)
   
   Generated-by: Claude Code following [the 
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
   
   The change was authored with Claude Code and reviewed by me against the 
chart conventions, the contributing docs and the charts cited above. I ran the 
chart tests and the schema hooks locally and I take responsibility for the 
content.
   


-- 
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]

Reply via email to