.NET 8 Debian images should be based on Bookworm

[richlander]

We expect that Debian Bookworm will ship before .NET 8. We did this same race with .NET 6 and Debian Bullseye. Fortunately, .NET 6 lost that race and we expect that .NET 8 will similarly lose the race with Bookworm.

For .NET 6, we shipped Bullseye images starting with .NET 6 Preview 1. We should use the same model here.

• https://www.debian.org/releases/bookworm/
• https://wiki.debian.org/DebianBookworm
• https://devblogs.microsoft.com/dotnet/announcing-net-6/#debian-11-bullseye

[richlander]

We need to decide on broad test coverage for Bookworm. Do we need a new test leg for this on dotnet/runtime (for example)?

@mmitche @ViktorHofer

[ViktorHofer]

In dotnet/runtime we currently test both Debian 10 and 11. Based on https://wiki.debian.org/DebianReleases, Debian 10 already reached EOL. Would it make sense to remove 10 and add 12?

[ViktorHofer]

cc @wfurt @ericstj @carlossanlop

[mthalman]

[Triage]
We should target .NET 8 Preview 1 to get the Debian Dockerfiles updated to be on Bookworm.

[lbussell]

Task tracking info for this work:

Distro: Debian 12 "Bookworm"

ImageBuilder Tasks

• Ensure that the ImageBuilder supports the new distro version in the code to generate the correct README display name from the version specified in the manifest
  • Add Debian 12 Bookworm to ImageBuilder's platform info docker-tools#1107

Nightly Branch Tasks

1. • Copy the Dockerfiles of the most recent version of that distro (or author new ones for an entirely new distro) and place them in a version-specific folder under their respective variants (runtime-deps, runtime, aspnet, sdk). Note: not all variants have a corresponding runtime-deps image.
2. • Modify the Dockerfiles as appropriate for any specific changes related to the new distro version
3. • Update manifest.json to reference the new set of Dockerfiles with the appropriate tags
     • Move any distro-specific floating tags to the newer version (e.g. 6.0-alpine)
4. • Update the test data to include the new distro version
5. • Update the tags metadata templates to include the new distro version
6. • Run the command to update the READMEs: .\eng\readme-templates\Get-GeneratedReadmes.ps1
7. • Run the command to update the image size baseline file: .\tests\performance\Validate-ImageSize.ps1 -UpdateBaselines
8. • Inspect generated changes for correctness
9. • Consider whether sample Dockerfiles should be authored if this is a new distro and them to the samples
10. • Run the command to build and test your changes: .build-and-test.ps1 -OS <os>
11. • Commit generated changes
12. • Create PR
13. • Get PR signoff
14. • Merge PR to nightly branch
15. • Wait for automatically queued CI build to finish on dotnet-docker-nightly pipeline (internal MSFT link)
16. • Confirm READMEs have been updated in Docker Hub

Main Branch Tasks

1. • After the product teams have signed off on the new distro, merge these changes to the main branch as part of the release process for the next .NET release
     • For Alpine, follow the policy to only update the floating alpine tag one month after the release of the new Alpine version. Since nightly will already have the floating tag updated, the initial release of the new Alpine version to main will need to account for this and keep it set to the older version for one month.
2. • Create an announcement (example: Alpine 3.10) unless the new distro is added only for pre-release versions in which the announcement would be incorporated in the pre-release notes.

[richlander]

@ViktorHofer -- That sounds like a great plan. Do you think you can do that before Preview 1 so that we have higher confidence on adopting Bookworm for our P1 container images?

I think doing that for dotnet/runtime is sufficient for now. We should consider doing same for ASP.NET, too, but the timing can be more relaxed. Who owns that?

[richlander]

@ashnaga -- Can you follow up with @ViktorHofer on ensuring we get some Bookworm validation ahead of Preview 1?

[ashnaga]

@ViktorHofer -- That sounds like a great plan. Do you think you can do that before Preview 1 so that we have higher confidence on adopting Bookworm for our P1 container images?

I think doing that for dotnet/runtime is sufficient for now. We should consider doing same for ASP.NET, too, but the timing can be more relaxed. Who owns that?

@wtgodbe for ASP.NET testing

[ViktorHofer]

@ViktorHofer -- That sounds like a great plan. Do you think you can do that before Preview 1 so that we have higher confidence on adopting Bookworm for our P1 container images?

Yes I can help with that but I think that @wfurt usually drives these platform / RID changes. Can someone please open an issue so that we can track that work in dotnet/runtime?

[richlander]

Can you do that @ashnaga?

[ashnaga]

Can you do that @ashnaga?

dotnet/runtime#81034

[wfurt]

It seems to have only OpenSSL 3 (so as Ubuntu 22). That will break QUIC and HTTP3 as current MsQuic release does not support OpenSSL3. Is there any possibility to talk to the vendors @richlander? Last time when this happened with OpenSSL older compat versions were around for a while so it was possible to update dependencies at slower pace.

[richlander]

That's exciting. No, I don't think there is any possibility to get this to change. Alpine (as of 3.17) has already moved to OpenSSL 3.0. AFAICT, OpenSSL 1.x is dead. Various components need to adapt.

Alpine context -> dotnet/runtime#80641

Our current plan is to offer .NET 8 solely with Bookworm (in terms of Debian). If there is enough demand, we could consider offering a bullseye-based image as well. However, the 8.0 tag will be based on Bookworm, for sure.

I don't know what the Debian plan is for OpenSSL version compat. Ubuntu 22.04 did not offer any compat within the official feeds.

[wfurt]

OK. That just puts more pressure on microsoft/msquic#2039
cc: @nibanks @ManickaP

[dougbu]

@wtgodbe for ASP.NET testing

@wtgodbe and I share infra ownership in ASP.NET

[dougbu]

We should consider doing same for ASP.NET, too, but the timing can be more relaxed.

After the Docker work is done, I'm now expecting we need to wait for microsoft/msquic#2039. Otherwise, we'll end up doing lots of work to skip tests on Bookworm that'll be thrown away soon (hopefully) thereafter.

[richlander]

I thought the same @dougbu ... However, you need the same capability to test on latest Alpine and Ubuntu (that are already in-market). That boils down to having the ability to "test on modern Linux".

We should get clarity from the MSQUIC team to see where they are at. We need a plan for delivering on this need in the first-half of 2023. If not, we have a significant problem. Also, the writing has been on the wall for some time with OpenSSL 3.

[dougbu]

However, you need the same capability to test on latest Alpine and Ubuntu (that are already in-market). That boils down to having the ability to "test on modern Linux".

Completely agree. Just have to frown every time we skip tests anywhere but on macOS (where certs are weird and keep getting weirder).

[richlander]

Who is our contact for the MSQUIC team? We should ensure that they are aware of all this.

[wfurt]

@nibanks should have visibility to the plans. AFAIK OpenSSL 3 is worked on but had some issues.
We may be able to consume some early images.
Out of curiosity, what is the issue with macOS @dougbu?

[dougbu]

Out of curiosity, what is the issue with macOS @dougbu?

We just have a large swath of tests that we had to disable on later macOS systems as they changed how some aspects of certificate validation works. I may be misremembering things of course but recall @javiercn was in the midst of it.

In any case, my comment wasn't really germane here.

[richlander]

Have we documented where users can expect HTTP3 to work? If not, it seems like we need to.

[wfurt]

https://learn.microsoft.com/en-us/dotnet/core/extensions/httpclient-http3#platform-dependencies

We only list OpenSSL 1.1 as needed dependency. Do not go to details about distributions as that can change easily.
Several users already wrongly assumed OpenSSL 3 is OK as well. In ideal case we would like it to some MsQuic doc about supported platforms as that can change as well independently of .NET releases.

And of course, distro vendors can step in and do their own packaging of MsQuic. I personally feel that would be better than navigating users to MS package feed.

[richlander]

And of course, distro vendors can step in and do their own packaging of MsQuic. I personally feel that would be better than navigating users to MS package feed.

That's unlikely if the upstream team doesn't adapt to changes in their dependencyies.

We only list OpenSSL 1.1 as needed dependency. Do not go to details about distributions as that can change easily.

That's not sufficient. Certainly as it relates to OpenSSL, it is pretty easy to follow for the big distros. Also, pretty soon everyone will be using OpenSSL 3.0, which will make it even easier to track.

[mthalman]

Documented breaking change at dotnet/docs#35953