You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Ash Berlin-Taylor <as...@apache.org> on 2022/03/07 21:12:19 UTC
K8s version/support policy: as long as K8s project, or as long as cloud providers?
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
Re: K8s version/support policy: as long as K8s project, or as long as cloud providers?
Posted by Dennis Akpenyi <de...@gmail.com>.
+1
On Tue 8. Mar 2022 at 16:21, Collin McNulty <co...@astronomer.io.invalid>
wrote:
> +1
>
--
Dr. Dennis Akpenyi, Airflow Core Developer, Astronomer Inc.
Re: K8s version/support policy: as long as K8s project, or as long as cloud providers?
Posted by Collin McNulty <co...@astronomer.io.INVALID>.
+1
Re: K8s version/support policy: as long as K8s project, or as long as cloud providers?
Posted by co...@astronomer.io.INVALID.
+1
> On Mar 7, 2022, at 7:08 PM, Vikram Koka <vi...@astronomer.io.invalid> wrote:
>
>
> +1
>
>> On Mon, Mar 7, 2022 at 3:01 PM Kaxil Naik <ka...@gmail.com> wrote:
>> +1
>>
>>> On Mon, 7 Mar 2022 at 21:17, Jarek Potiuk <ja...@potiuk.com> wrote:
>>> +1
>>>
>>>> On Mon, Mar 7, 2022 at 10:12 PM Ash Berlin-Taylor <as...@apache.org> 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
Re: K8s version/support policy: as long as K8s project, or as long as cloud providers?
Posted by Vikram Koka <vi...@astronomer.io.INVALID>.
+1
On Mon, Mar 7, 2022 at 3:01 PM Kaxil Naik <ka...@gmail.com> wrote:
> +1
>
> On Mon, 7 Mar 2022 at 21:17, Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> +1
>>
>> On Mon, Mar 7, 2022 at 10:12 PM Ash Berlin-Taylor <as...@apache.org> 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
>>>
>>
Re: K8s version/support policy: as long as K8s project, or as long as cloud providers?
Posted by Kaxil Naik <ka...@gmail.com>.
+1
On Mon, 7 Mar 2022 at 21:17, Jarek Potiuk <ja...@potiuk.com> wrote:
> +1
>
> On Mon, Mar 7, 2022 at 10:12 PM Ash Berlin-Taylor <as...@apache.org> 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
>>
>
Re: K8s version/support policy: as long as K8s project, or as long as cloud providers?
Posted by Jarek Potiuk <ja...@potiuk.com>.
+1
On Mon, Mar 7, 2022 at 10:12 PM Ash Berlin-Taylor <as...@apache.org> 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
>