Experimental network.interface.name slipped into stable semconv due to semconv bug

[lmolkova]

network.interface.name now appears in the stable part of semantic conventions

opentelemetry-cpp/api/include/opentelemetry/semconv/network_attributes.h

Line 25 in ced7986

static constexpr const char *kNetworkInterfaceName = "network.interface.name";

due to open-telemetry/semantic-conventions#1777 - there was no stability set on it. Combining it with

opentelemetry-cpp/buildscripts/semantic-convention/templates/registry/weaver.yaml

Line 37 in ced7986

"exclude_stability": if $filter == "any" then [] else ["experimental"] end,

it results in network.interface.name appearing as stable and it seems to be part of a stable release now.

---

The question now is how to handle it:

1. Do a breaking change - this attribute is very new and very unlikely to be used by anyone. Still, this is a reputational problem
   This is easy and can be done with this change similar to Exclude attributes without stability from stable semconv part opentelemetry-python#4391

   - "exclude_stability": if $filter == "any" then [] else ["experimental"] end,
   + "exclude_stability": if $filter == "any" then [] else ["experimental", "", null] end,

2. Keep it around, hardcode in jinja template as deprecated. Here's how it can be done main...lmolkova:opentelemetry-cpp:workaround-network-interface-name

---

Additional context:

semconv 1.30.0 are coming out in the next few days and will have this attribute as experimental again. The next codegen would remove this attribute from stable part.

[marcalff]

Thanks for the report.

The release notes for opentelemetry-cpp v1.19.0 are now updated with an errata.

This is sufficient in my opinion, there is no need to run code generation again and make a new release just for that, given that this will be resolved with the next code generation.

Keeping this issue opened, to make exclude_stability more defensive as proposed, to prevent similar issues in the future.

[marcalff]

@lmolkova

The following code:

"exclude_stability": if $filter == "any" then [] else ["experimental", "", null] end,

is very fragile.

Every time a new stability value is added in semantic conventions, like "development", the semantic convention will be treated as stable, right ?

Could weaver expose include_stability instead ?

[lmolkova]

@marcalff absolutely should - open-telemetry/weaver#569

The suggestion above is for immediate actions (if you decide to take any)

[lmolkova]

Every time a new stability value is added in semantic conventions, like "development", the semantic convention will be treated as stable, right ?

sorry, missed this one. For this specific case (exclude_stability: ["experimental"]) weaver would handle all non-stable (development, rc, etc) levels as experimental.

The null was the worst as it happened to be neither stable, nor experimental

[marcalff]

Blocked by:

• Add include_stability config into semconv_grouped_attributes weaver#569
• Bump otel/weaver from v0.12.0 to v0.13.0 semantic-conventions#1893
• Update stability levels from experimental -> development semantic-conventions#1889
• Set span kind on span definitions or change ambiguous spans to attribute groups semantic-conventions#1890

so we can change the weaver config file once a weaver+semconv release is ready.