potiuk commented on PR #35214: URL: https://github.com/apache/airflow/pull/35214#issuecomment-1785024167
> since cloud providers are way more up to date with K8S versions and also Apache airflow is not astronomer and we could have the same policy that we have with python and postgres I do not think the rule we have is "Astronomer" rule - it's been proposed by @ashb quite long time ago https://lists.apache.org/thread/fr3tdy4nc8ywo3p0hpy9h04nyv1kldsy, and a few people agreed it makes sense back then without opposal (coincidentally they were all from Astronomer + me :D) . But the discussion has (as I re-read it now) quite a good justification on why keep it until it is likely a number of people still use it. A lot of people keep they old clusters running for as long as they can and only forced migration will keep them to move. I believe k8s is a bit different than say "Postgres" - in the sense that it has many more internal components that might make things more difficult to migrate than say migrating the database. K8S is a conglomerate of about a hundred or so different - independently released components internally so there might be one small single thing that might prevent particular installation to migrate to a newer version without some serious pains. But I agree, it would be quite a bit more consistent to have "EOL" as a cut-off time for "software" we release - because we do not run "service". Maybe worth to restart the discussion on devlist and see what people think about it TODAY @raphaelauv ?. I'd support changing it to EOL only. Just personally - I am (for now) generally fine with both approaches but I'd prefer following the "EOL" route. I see why it is good to keep it a little longer, but also I see how strictly following EOL from K8S might actually drive people to update things. But this might be mandated in the future actually, so we might want to do it even now anticipating what will happen. Putting my `security` hat on - we will likely in the future HAVE TO add the rule of not supporting EOL software because of security regulations. We cannot rely on Amazon or Google releasing fixes to K8S "to the public" and when we "put software on the market" (this is what making a release does) we have to make sure we do it without relying on software that does not have security fixes maintenance. The landscape is changing a lot with Cyber Resilience Act and similar US legislations that all are going to be codified in 2024 and will likely have to be implemented 2/3 years from the moment they pass. It will be legally and financially costly for companies NOT to upgrade the software with latest security fixes and use software that is known it will not receive security fixes. So basically what it might mean (this is what is the spirit of the regulations at least - the regulations and standards are not yet set in stone) that if someneone finds a fix in K8S that is EOL and we (Airflow) rely on it, we (Airflow/ASF) will have to (somehow) make sure that our users will get a fix. Making it clear that we do not support EOL software, removes that obligation from us. It is of course pretty messy with smaller libraries and their dependencies etc. But there, vendoring-in and relasing security fixes is much easier for us even if we need to, rather than advising our customers on how to patch their k8s. So explicitly marking EOL software as not supported in latest version of Airflow is simply smart thing to do to prevent any responsibilities we might get. I think we will see our industry shifting in the coming years from "costly to migrate so let's not think about it" to "costly to NOT migrate so let's actively manage it". But we will yet see what effect those regulations might have. But anticipating that - I think using EOL as cut-off day for us is a good idea. -- 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]
