Image glibc/musl path layout convention and integration with opentelemetry-operator

[jack-berg]

Background

At grafana, we've been working to integrate the injector into the opentelemetry-operator. The operator publishes its own images. The layout of these images is incompatible with the injector's config model. Therefore, we're forced to consider whether:

1. we should adjust the injector's image layout expectations to match the operator
2. or to adjust the injector's config to accommodate the operator's image layout
3. or to expect the operator to publish images with an alternative layout matching the injector's expectations

Updating the operator to change its image layout is a longer term solution, so I assume we want to take path 1 or 2 in the short term.

Problem

The injector's current layout convention for python and dotnet differs from the operator's.

Dotnet — the injector expects glibc/ and musl/ subdirectories under the prefix, which duplicates shared managed assemblies (AdditionalDeps, store, net) across both variants even though they are identical. The operator's image (which reflects the upstream release artifact structure) avoids this:

# Injector (current)            # Operator / upstream
{prefix}/glibc/linux-x64/      {prefix}/linux-x64/        ← glibc native
{prefix}/glibc/AdditionalDeps/ {prefix}/linux-musl-x64/   ← musl native
{prefix}/glibc/store/          {prefix}/AdditionalDeps/   ← shared (one copy)
{prefix}/musl/linux-musl-x64/  {prefix}/store/
{prefix}/musl/AdditionalDeps/  {prefix}/net/
{prefix}/musl/store/           ...
...

Python — the injector expects {prefix}/glibc/ and {prefix}/musl/. The operator's image contains /autoinstrumentation/ (glibc) and /autoinstrumentation-musl/ (musl).

Approach 1: Change the injector's convention to match the operator's (preferred)

Update dotnet.zig, python.zig, and the packaging scripts to expect the operator's layout natively. For dotnet this also eliminates the redundant duplication of shared assets, reducing the DEB/RPM dotnet payload by ~50%.

Pro: Simpler — a single prefix is sufficient. Aligns with the operator's stable conventions and positions the injector to work directly with operator images without extra config as the operator's publishing cadence matures.

Con: Breaking change to the existing path convention. Encode operator naming conventions into injector image layout.

Approach 2: Add explicit per-variant path config

Add new config keys/env vars for glibc and musl paths independently (e.g. python_auto_instrumentation_agent_glibc_path, dotnet_auto_instrumentation_agent_musl_path_prefix, etc.) that override the convention when set.

Pro: Fully backward compatible.

Con: Increases configuration surface area. For dotnet the mental model becomes confusing — shared assets and per-variant native libs would be governed by different config options that interact in non-obvious ways.

[jack-berg]

Do some additional on dotnet-auto-instrumentation's and LFS recommendations.

If the operator aligns with dotnet-auto-instrumentation's recommendation, it would be a strong signal for the operator to align with that convention.