-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.NET 8 Debian images should be based on Bookworm #4322
Comments
We need to decide on broad test coverage for Bookworm. Do we need a new test leg for this on dotnet/runtime (for example)? |
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? |
[Triage] |
Task tracking info for this work: Distro: Debian 12 "Bookworm" ImageBuilder Tasks
Nightly Branch Tasks
Main Branch Tasks
|
@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? |
@ashnaga -- Can you follow up with @ViktorHofer on ensuring we get some Bookworm validation ahead of Preview 1? |
@wtgodbe for ASP.NET testing |
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? |
Can you do that @ashnaga? |
|
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. |
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 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. |
OK. That just puts more pressure on microsoft/msquic#2039 |
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. |
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. |
Completely agree. Just have to frown every time we skip tests anywhere but on macOS (where certs are weird and keep getting weirder). |
Who is our contact for the MSQUIC team? We should ensure that they are aware of all this. |
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. |
Have we documented where users can expect HTTP3 to work? If not, it seems like we need to. |
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. 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.
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. |
Because the dotnet project ran into issues with bullseye releases and OpenSSL, the default image now defaults to a buster release. https://hub.docker.com/repository/docker/urothis/nwserver/tags?page=1&ordering=last_updated The default image and -buster resolve to the same image currently. Dotnet 8 should resolve this dependency issue. dotnet/dotnet-docker#4322 Looks to have already been merged, so we should see all resolve later this year.
Documented breaking change at dotnet/docs#35953 |
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.
The text was updated successfully, but these errors were encountered: