And Python default images are Bullseye now. On Mon, Feb 14, 2022 at 2:13 PM Jarek Potiuk <[email protected]> wrote:
> Buster end of life is August 2022 of course :) > > On Mon, Feb 14, 2022 at 2:12 PM Jarek Potiuk <[email protected]> wrote: > >> Hello everyone, >> >> I am just about to complete preparation to make our images (and CI) work >> on Debian 11 images (Bullseye) vs Debian 10 (Buster). All looks (almost) >> good, but I would like to tap into the collective wisdom of the group here >> to decide on next steps (and maybe propose a policy we might be following >> in the future). The last change that allows to easily switch between the >> two is in reviee: https://github.com/apache/airflow/pull/21546 >> >> Context/where we are: >> >> For quite a while we used Buster (Debian 10) as our base image. Buster is >> a stable release and it is being replaced with the next >> stable release Bullseye (Debian 11). >> >> The Release schedule is here: https://wiki.debian.org/DebianReleases >> >> The most important facts from those: >> * Bullseye was introduced in August 2021 (6 months ago) and has no >> end-of-life yet >> * Buster was introduced in July 2019 and its end of life is ~ August 2020 >> (approx. 6 months from now) >> >> Python default images are (as of a few months), However they provide (as >> usual -buster and -bullseye) specific images. >> >> The Bullseye switch is really needed to support ARM (M1) images because >> of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989604 (still >> unresolved on Buster). >> >> It seems appropriate to switch to Bullseye now, however there is one >> problem with it - MSSQL drivers do not yet support Bullseye. I've reached >> out to the maintainers and await their answer when it might be available: >> https://github.com/MicrosoftDocs/sql-docs/issues/7255#issuecomment-1037097131 >> . This is the last blocker that prevents full switch (failing PR for a full >> switch is https://github.com/apache/airflow/pull/21378). All tests pass >> except MSSQL. >> >> But I think we need to proceed, regardless of the timeline and switch to >> Bullseye. >> >> Question: >> >> We need to decide on what support we give our users in the images now, in >> the 2.3.0 release and in the future. We have no policies for that yet, so >> it might be a good time to decide now. Some of the users might "rely" on >> the Buster being used by the images as they might have some incompatible >> libraries (similarly to MSSQL). And I believe we need to support Buster >> till at least the end of life of it. >> >> This support might be twofold: >> >> * we can publish in https://hub.docker.com/r/apache/airflow our binary >> images with Buster and/or Bullseye >> * we can only publish one of those (and change from Buster to Bullseye >> for 2.3.0) but users will be able to build their own custom images using >> our Dockerfile for either of those. >> >> Proposal: >> >> I think there are multiple reasons why we should support both Bullseye >> and Buster for the coming 6 months. We might build both images in CI and >> add a new "matrix" dimension and run most tests on Bullseye but some tests >> on Buster (specifically MSSQL until Bullseye is supported). >> >> We can publish both types of images (with -buster, -bullseye suffixes >> same as Python) but the default image should be changed to Bullseye. >> >> This will add some complexity (and build overhead) to our CI, but I think >> it's worth it. >> >> Then we could drop support and release the -buster images after it >> reaches end of life (but we will leave the users possibility of building >> their own buster images without guarantee that it will work). >> >> I think this might become our Policy also for the future (6 months before >> end-of-life we switch by default to the new stable and provide built images >> until end-of-life). >> >> WDYT? Does it look like a good proposal? >> >> J. >> >> >> >> >> >> >> >> >>
