Promote a selection of k8s and container attributes to beta

[ChrsMark]

Changes

Similar to #3215.
This is part of #3120. The purpose of this PR is to again advertise the intention towards having those attributes as Release Candidates soon.

open-telemetry/opentelemetry-collector-contrib#45447 aims to use the alpha version in the Collector Contrib already.

All suggested attributes are already in use from several Collector components as described at #3120 (comment):

• k8sattributes processor (from metadata.yaml and extract::metadata)
• resourcedetection processor
• filelog receiver

Closes #3381

Important

Pull requests acceptance are subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above, may be automatically rejected and closed.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[thompson-tomo]

Note mediumpink is not a named web color https://www.w3schools.com/colors/colors_names.asp hence docs are using the default aka green. I would change it to lightpink and then re-generate docs.

[ChrsMark]

@open-telemetry/semconv-k8s-approvers PTAL

[joaopgrassi]

@ChrsMark something looks wrong with the commit ids, the diff for the check fails. Maybe a rebase fixes it.

[ChrsMark]

@joaopgrassi thank's for the heads-up, should be good now

[trask]

before merging, I'd like to discuss since we haven't used beta in semconv previously

• what's the concrete value / implication of going from release to beta? if it's just to advertise the intention of going to release candidate soon, maybe a blog post would be better way to accomplish?
• what does this imply about all of the other semconv that are (still in) development instead of (the now used) beta

[joaopgrassi]

While reviewing, I re-read https://opentelemetry.io/docs/specs/otel/document-status/. To me moving to Alpha sounds like the natural path. If now the sig believes that there's high confidence in the current design, meaning no new features/breaking changes, then I guess moving directly to RC makes sense.

[ChrsMark]

what's the concrete value / implication of going from release to beta? if it's just to advertise the intention of going to release candidate soon, maybe a blog post would be better way to accomplish

The idea is to go through the stability levels described at https://opentelemetry.io/docs/specs/semconv/general/semantic-convention-groups/#group-stability before graduating as stable. Moving from one stage to the next one per release allows us to bump the version in the Collector with PRs like open-telemetry/opentelemetry-collector-contrib#45447. We could go directly to release_candidate skipping alpha and beta, but I felt that going through the full stability level steps will allow us to gradually update both the semconv part but the Collector part as well in a less "aggressive" way.

The ultimate goal (of the K8s SIG in alignment with the Collector SIG as per #3119) is to transition the k8sattributes processor into using the beta/release_candidate respective semconvs behind a feature gates pair (see open-telemetry/opentelemetry-collector-contrib#45307) following the Collector's guidelines as part of the component's stability effort. This will then allow us to release these semconvs as stable once we use them for a while behind the feature gate pair.

Since we have lot's of work ahead I would advertise this change with a blogpost once we have these semantic conventions in release_candidate level and already introduced in the Collector's k8sattributes processor behind the feature gate pair.

I would target for the release_candidate before KubeConEU 26' if possible so it can also be announced there. (However this would imply that we will have 2 releases of SemConv project in the following 1.5 months, so not sure if that's realistic. We could have one next week (early Feb) and then one early March)

Let me know what you think @trask @joaopgrassi.

[ChrsMark]

@open-telemetry/specs-semconv-approvers let us know if there is anything missing here

[jsuereth]

Should this also be moving the entities to beta?

[trask]

@ChrsMark thanks, sounds like a good plan 👍

[ChrsMark]

Should this also be moving the entities to beta?

Entities have not been included since they are not introduced yet in k8sattributes processor. For the Collector's component stability (open-telemetry/opentelemetry-collector-contrib#44483) we only need the attributes by now. We discussed that recently with @dmitryax and we agreed that we wouldn't like to block v1 of Collector's components on entities' work.

So @jsuereth I think entities can wait unless we have a specific need for this?

[dmitryax]

I think it makes sense to promote the attribute names separately from the entities as a whole at this point. It’s important to provide more assurance to users that we’re not planning to change the names themselves in the future even as part of the entity work. I believe many systems rely on these naming conventions already.

[jsuereth]

I'm just trying to make sure we have a consistent policy around stabilization here with attributes, entities + signals.

I'm fine stabilizing attributes then revisiting stabilization for entities.