Good news from today - I got the response from Microsoft and it seems that MSSQL Bullseye support is going to be released today :) . So at least that problem is going to be solved. Still the question of whether we should build/release both Bullseye and Buster ?
J. On Mon, Feb 14, 2022 at 2:14 PM Jarek Potiuk <[email protected]> wrote: > > 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. >>> >>> >>> >>> >>> >>> >>> >>>
