`<ContainerFamily>alpine-extra</ContainerFamily>` must be set when `<InvariantGlobalization>false</InvariantGlobalization>`

[richlander]

I'm using container publishing. I would hope that the alpine-extra image was used when InvariantGlobalization == false.

rich@mazama:~/hello-dotnet$ cat hello-dotnet.csproj 
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <RootNamespace>hello_dotnet</RootNamespace>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <InvariantGlobalization>false</InvariantGlobalization>

    <!-- Publishing properties -->
    <EnableSdkContainerSupport>true</EnableSdkContainerSupport>
    <PublishTrimmed>true</PublishTrimmed>
    <!-- <ContainerFamily>alpine-extra</ContainerFamily> -->
    <ContainerRepository>hello-dotnet-alpine-trimmed</ContainerRepository>
  </PropertyGroup>

</Project>
rich@mazama:~/hello-dotnet$ dotnet publish /t:PublishContainer --os linux-musl
MSBuild version 17.9.4+90725d08d for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
  hello-dotnet -> /home/rich/hello-dotnet/bin/Release/net8.0/linux-musl-x64/hello-dotnet.dll
  Optimizing assemblies for size. This process might take a while.
  hello-dotnet -> /home/rich/hello-dotnet/bin/Release/net8.0/linux-musl-x64/publish/
  Building image 'hello-dotnet-alpine-trimmed' with tags 'latest' on top of base image 'mcr.microsoft.com/dotnet/runtime-deps:8.0-alpine'.
  Pushed image 'hello-dotnet-alpine-trimmed:latest' to local registry via 'docker'.

Environment:

$ dotnet --version
8.0.201
$ cat /etc/os-release | head -n 1
PRETTY_NAME="Ubuntu 23.10"
$ which dotnet
/home/rich/dotnet/dotnet

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[baronfel]

duplicate of https://github.com/dotnet/sdk-container-builds/issues/533, which we have not yet implemented. This should be part of our work for 8.0.300.

Not entirely, see below.

[baronfel]

Ok - we opted into the -extra default only for AOT-published applications. Should trimmed behave the same?

[richlander]

I'm good with:

• PublishTrimmed=true + linux-musl + invariant=true => alpine
• PublishTrimmed=true + linux-musl + invariant=false => alpine-extra
• PublishAOT + linux-musl + invariant=true => alpine
• PublishAOT + linux-musl + invariant=false => alpine-extra

Any fixes to that can be safely made in servicing since it (AFAIK) is just the extra cases. I cannot imagine people wanting the current behavior.

It isn't clear to me that special casing chiseled is all that useful. I WANT to do it to encourage it, but haven't come up with a model that I think of as a clear win. If we can come up with something, I'm definitely open to it.

[richlander]

We could consider (in 8.0.300 or 9.0.100):

• PublishTrimmed=true + linux + invariant=true => jammy-chiseled
• PublishTrimmed=true + linux + invariant=false => jammy-chiseled-extra

There are (at least) two problems with this:

• It might be a shock to end up with no shell. What would they specify to get back? debian-bookworm?
• We're keeping people on jammy when they could be on noble.

The former problem is the more severe. However, we could switch from jammy to noble in a feature band.

This is why I come back to ContainerFamily=jammy-chiseled[-extra] being an OK compromise. It's explicit with reliable behavior. Alpine folks have to say something extra and so do chiseled folks. If you squint, it is the same.

[baronfel]

so with the linked PR, It might be easier to see in truth table form (at least as a new test I added records it):

    [InlineData(true, false, "linux-musl-x64", true, "mcr.microsoft.com/dotnet/runtime-deps:8.0-alpine")]
    [InlineData(true, false, "linux-musl-x64", false, "mcr.microsoft.com/dotnet/runtime-deps:8.0-alpine-extra")]
    [InlineData(false, true, "linux-musl-x64", true, "mcr.microsoft.com/dotnet/nightly/runtime-deps:8.0-alpine-aot")]
    [InlineData(false, true, "linux-musl-x64", false, "mcr.microsoft.com/dotnet/runtime-deps:8.0-alpine-extra")]

    [InlineData(true, false, "linux-x64", true, "mcr.microsoft.com/dotnet/runtime-deps:8.0-jammy-chiseled")]
    [InlineData(true, false, "linux-x64", false, "mcr.microsoft.com/dotnet/runtime-deps:8.0-jammy-chiseled-extra")]
    [InlineData(false, true, "linux-x64", true, "mcr.microsoft.com/dotnet/nightly/runtime-deps:8.0-jammy-chiseled-aot")]
    [InlineData(false, true, "linux-x64", false, "mcr.microsoft.com/dotnet/runtime-deps:8.0-jammy-chiseled-extra")]
    [Theory]
    public void TheBigMatrixOfTrimmingInference(bool trimmed, bool aot, string rid, bool invariant, string expectedImage)

here's the logic as of the linked PR (currently targeting 8.0.300). The differences from what you have above are:

• AOT, invariant applications on both linux platforms use the nightly -aot images
• the trimmed application proposal for jammy already is the way the world works for AOT'd non-musl linux RIDs, so I'm not sure it would be such a big break. If you recall, back when we were talking about the behavior for GA release, we had a hypothesis that folks who were AOTing would want that slimmed down container. I guess the question is - would Trimmers want the same?

[richlander]

the trimmed application proposal for jammy already is the way the world works for AOT'd non-musl linux RIDs,

I just came to the same conclusion playing with AOT. However, there are way more people (presumably) using trimming than AOT.

What about my two questions/problems above? How would you resolve those?

[richlander]

We need a table for all the inferencing. It's hard for folks to remember.

[baronfel]

Digging a bit from memory here - IIRC the thread of logic we were following to promote jammy-chiseled was:

• we have a lot of useage of alpine, customers say this is because the image size is so much smaller
• we have a glibc-based linux image variant that can approach that image size
• for size-sensitive workloads we should default to that smaller image

I think that's a reasonable line of inference, as long as there's an escape hatch - and we provided one with either explicit ContainerFamily or explicit ContainerBaseImage property specification.

I will say that so far I haven't see any complaints or issues from folks that are doing AOT and using the SDK containerization feature - though that could definitely be because it's harder to use AOT than it is to do trimming, for example.