[processor/k8sattributes] move k8sattr.labelsAnnotationsSingular.allow feature gate to beta

[odubajDT]

Description

Link to tracking issue

Fixes #44693

[ChrsMark]

I guess we should not move this to beta until we complete open-telemetry/semantic-conventions#3120?

I just realise that the amount of breaking changes between current SemConv and the k8sattributesprocessor component is fortunately not really big.

Based on the analysis of open-telemetry/semantic-conventions#3120 it's only the labels and the container.image.tag. #44700 also proved that.

In this, how about we deprecate this specific feature gate that's only about the labels and go directly with the generic k8sattributes.semconv.k8s.enableStable and k8sattributes.semconv.k8s.disableLegacy including the container.image.tag rename to container.image.tags?

(We should get a final confirmation from #43869 for the feature gate approach)

The feature gate pair should remain alpha until we complete #44700.

[odubajDT]

I guess we should not move this to beta until we complete open-telemetry/semantic-conventions#3120?

I just realise that the amount of breaking changes between current SemConv and the k8sattributesprocessor component is fortunately not really big.

Based on the analysis of open-telemetry/semantic-conventions#3120 it's only the labels and the container.image.tag. #44700 also proved that.

In this, how about we deprecate this specific feature gate that's only about the labels and go directly with the generic k8sattributes.semconv.k8s.enableStable and k8sattributes.semconv.k8s.disableLegacy including the container.image.tag rename to container.image.tags?

(We should get a final confirmation from #43869 for the feature gate approach)

The feature gate pair should remain alpha until we complete #44700.

Good point, I guess deprecating the feature gate is a special case. Do we have an approximate date when the generic k8sattributes.semconv.k8s.enableStable and k8sattributes.semconv.k8s.disableLegacy feature gates might be realistic to be accepted and used in the component?

My thinking is: If it takes long and we have already a feature gate in beta (this one), there is a chance, that until the generic feature gates become a realistic option, we might have this one already in stable and therefore reduce the amount of changes handled by the generic feature gates, since the labels/annotations at that time will met the SemConv. Just thinking out loud to keep things moving, but I am fine with both approaches.

Let me know what you think.

[ChrsMark]

Good point, I guess deprecating the feature gate is a special case. Do we have an approximate date when the generic k8sattributes.semconv.k8s.enableStable and k8sattributes.semconv.k8s.disableLegacy feature gates might be realistic to be accepted and used in the component?

Based on recent discussions took place this week in both the Collector SIG and the System SemConv SIG meetings, I can say there is agreement on having feature gate pairs per component. @mx-psi will be writing something sth down about this soon. So I think we can wait a bit and go with this approach. In any case I would be hesitant to promote the current feature gate to beta (enabled by default) until we have open-telemetry/semantic-conventions#3120.

Update: Based on the current progress of open-telemetry/semantic-conventions#3120, where all listed attributes now exist as semantic conventions, I think it would make sense to start putting them behind a common (component specific), alpha feature gate.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[odubajDT]

closed in favor of #45307