+1 On Mon, Mar 7, 2022 at 3:01 PM Kaxil Naik <[email protected]> wrote:
> +1 > > On Mon, 7 Mar 2022 at 21:17, Jarek Potiuk <[email protected]> wrote: > >> +1 >> >> On Mon, Mar 7, 2022 at 10:12 PM Ash Berlin-Taylor <[email protected]> wrote: >> >>> Hey everyone, >>> >>> So Kubernetes 1.20 has now reached end of life in the upstream project, >>> and as per our policy >>> https://github.com/apache/airflow/blob/main/README.md#support-for-python-and-kubernetes-versions >>> and discussed on list last year >>> https://lists.apache.org/thread/3m6hfxfhfhvo14kmhc38s2fgz1jfgz0y >>> someone has opened a PR to drop support for 1.20. (Thanks Raphael >>> https://github.com/apache/airflow/pull/21902) >>> >>> I would like to propose we extend the time we support a k8s version to >>> "as long as it is supported by at least two major clouds". >>> >>> For instance, 1.20 is still supported by AWS (until Sept 2022, < >>> https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html>)and >>> GCP (until August 2022, < >>> https://cloud.google.com/kubernetes-engine/docs/release-schedule>) >>> >>> My main driver for suggesting this is to make it easier for users to >>> upgrade -- upgrading the python version of Airflow is isolated to just >>> Airflow and DAGs, but the version of a Kube cluster can often affect the >>> entire company. >>> >>> Data Engineer: "Dear Central Infra Team: please could you upgrade the >>> version of our central Kube cluster so I can update Airflow" >>> >>> I've been in plenty of companies where this would not play out well. >>> >>> So by loosening the Kube version to support common lifetimes it >>> hopefully makes it easier for our users to stay up to date with Airflow >>> releases. >>> >>> What do people think? >>> >>> (Assuming no complaints, I'll PR to change the guidance in a few days) >>> >>> -ash >>> >>
