Limit pod_name length to HOST_NAME_MAX

[csp33]

Closes #36326

[potiuk]

How do you plan to tackle backwards compatibilty. Imagine you are upgrading Airflow and thera are long running Pods still running being adopted by the new Airflow with limited length/ What is your plan to do with it?

[dirrao]

How do you plan to tackle backwards compatibilty. Imagine you are upgrading Airflow and thera are long running Pods still running being adopted by the new Airflow with limited length/ What is your plan to do with it?

Pod adoption is seamless. As we are not using pod name to deduce anything. Its just a reference to identify the dag and task from pod while debugging.

[dirrao]

@csp33
Nice work. LGTM. we have seen problem where K8 cluster not able to resolve/update DNS because of when they exceeds max length 63.

[csp33]

How do you plan to tackle backwards compatibilty. Imagine you are upgrading Airflow and thera are long running Pods still running being adopted by the new Airflow with limited length/ What is your plan to do with it?

K8s executor does not use the pod name to adopt previous TIs, it uses the queued_by_job_id field instead:

airflow/airflow/providers/cncf/kubernetes/executors/kubernetes_executor.py

Line 581 in 73cd0d5

f"airflow-worker={scheduler_job_id},{POD_EXECUTOR_DONE_KEY}!=True"

[dirrao]

Awesome work. LGTM.

[potiuk]

How do you plan to tackle backwards compatibilty. Imagine you are upgrading Airflow and thera are long running Pods still running being adopted by the new Airflow with limited length/ What is your plan to do with it?

K8s executor does not use the pod name to adopt previous TIs, it uses the queued_by_job_id field instead:

airflow/airflow/providers/cncf/kubernetes/executors/kubernetes_executor.py

Line 581 in 73cd0d5

f"airflow-worker={scheduler_job_id},{POD_EXECUTOR_DONE_KEY}!=True"

Cool