Recommeded resource attributes

[zeitlinger]

Description:

Updates the recommended resource attributes to comply with the semantic conventions.

https://github.com/open-telemetry/semantic-conventions/blob/main/docs/non-normative/k8s-attributes.md

Technically, it's a breaking change - looking for feedback if it's OK to change as is.

Link to tracking Issue(s):

• Resolves: Kubernetes: How to populate resource attributes based on attributes, labels and transformation semantic-conventions#1756

Testing:

Adapted existing tests.

Documentation:

Adapted existing docs.

[iblancasa]

LGTM. Please fix the CI

[iblancasa]

We discussed about this PR during the SIG call. Some comments:

1. Could you add a feature gate to avoid the breaking change right now and give some time to users to upgrade?
2. Are the semantic convention changes already released?
3. Is there something we can do to avoid the breaking change?

[iblancasa]

Please add more info about the exact changes that need to be done for the operator.

Also, provide some kind of recommendation regarding upgrading.

[zeitlinger]

the subtext has all changes - is that sufficient?

The subtext should also cover what you need to consider for upgrading.

[zeitlinger]

We discussed about this PR during the SIG call. Some comments:

1. Could you add a feature gate to avoid the breaking change right now and give some time to users to upgrade?

yes, we could - but I'm not sure if that's really warranted in this case:

1. the exact format of the version is unlikely to affect anyone
2. the well-known labels need an extra opt-in already

See

https://github.com/open-telemetry/opentelemetry-operator/pull/3797/files#diff-5fd4df0f3bace6e5f00b361ea2060d8ddf95cf8136445af1a530c2b81afe2c2bR17-R21

Having said that, I'm happy to add a flag if we decide to do so

2. Are the semantic convention changes already released?

yes, see https://github.com/open-telemetry/semantic-conventions/blob/main/docs/non-normative/k8s-attributes.md

3. Is there something we can do to avoid the breaking change?

we could add a different flag for the well-known attributes and deprecate the old flag
that would only leave the version format - which is less likely to affect anyone

[zeitlinger]

@iblancasa please check again

[zeitlinger]

just found a missing piece: k8s.namespace.name should also be translated to service.namespace

[zeitlinger]

@iblancasa now it should be complete 😄

[swiatekm]

I am ok with this going in without a feature flag, but I'd like opinions from other maintainers before we merge.

[iblancasa]

I am ok with this going in without a feature flag, but I'd like opinions from other maintainers before we merge.

I thing we should include this using a feature gate to give users some time to migrate. But not strong opinion.

[swiatekm]

I am ok with this going in without a feature flag, but I'd like opinions from other maintainers before we merge.

I thing we should include this using a feature gate to give users some time to migrate. But not strong opinion.

Rather than a feature gate, I think I'd prefer some instructions on how to get the old behaviour by changing resource labels.

[zeitlinger]

I am ok with this going in without a feature flag, but I'd like opinions from other maintainers before we merge.

I thing we should include this using a feature gate to give users some time to migrate. But not strong opinion.

Rather than a feature gate, I think I'd prefer some instructions on how to get the old behaviour by changing resource labels.

I've added a section in the changelog

[zeitlinger]

@iblancasa @swiatekm please check again

[jaronoff97]

looks great, thanks for your work here @zeitlinger !