amoghrajesh commented on PR #35748:
URL: https://github.com/apache/airflow/pull/35748#issuecomment-1823829483
> I think we have ways to generate different resources for 1.28+ . I believe
helm takes K8s version into account when generating resources. Look in our
chart I think we have a few cases of that
@potiuk I did check for this. Unfortunately, we do not seem to have such a
mechanism. We will eventually need it to get the 1.28 features and this is also
useful in a long run.
I was thinking of introducing an env variable at the worker deployment level
where the main container has the env that holds the kube version. We can
conditionally set the args for containers and do a lot more things too.
For example:
```
containers:
- name: base
env:
- name: KUBE_VERSION
valueFrom:
configMapKeyRef:
name: your-scripts
key: kubeVersionScript.sh
volumeMounts:
- name: script-volume
mountPath: /scripts
args:
{{- if eq .Env.KUBE_VERSION "1.25" }}
- /bin/sh
- -c
- |
echo "Kube version is 1.25, do something"
{{- else if eq .Env.KUBE_VERSION "1.26" }}
- /bin/sh
- -c
- |
echo "Kube version is 1.26, do something else"
{{- else }}
- /bin/sh
- -c
- |
echo "Kube version is not 1.25 or 1.26, do default"
{{- end }}
initContainers:
- name: init-script
image: your-image
command: ["/bin/sh", "-c"]
args:
- |
export KUBE_VERSION=$(source /scripts/kubeVersionScript.sh)
volumeMounts:
- name: script-volume
mountPath: /scripts
volumes:
- name: script-volume
configMap:
name: your-scripts
```
Thoughts?
cc @jedcunningham looping you in. Pls correct me if I am misinformed here
--
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: commits-unsubscr...@airflow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
