move faas to registry

[trisch-me]

Changes

Move faas attributes to the registry

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• CHANGELOG.md updated for non-trivial changes.
• schema-next.yaml updated with changes to existing conventions.

[AlexanderWert]

Blocked by: open-telemetry/build-tools#242

[joaopgrassi]

Blocked by: open-telemetry/build-tools#242

@AlexanderWert Now thinking, is this really blocked? The attributes that were defined as resource before are not used on spans or metrics, so it should be fine to define them in the registry as resource for now, no? That would unblock this PR.

[AlexanderWert]

Blocked by: open-telemetry/build-tools#242

@AlexanderWert Now thinking, is this really blocked? The attributes that were defined as resource before are not used on spans or metrics, so it should be fine to define them in the registry as resource for now, no? That would unblock this PR.

The problem is not only on single attributes but even when a single namespace contains a mix of resource and semantic attributes, which is the case here (for example: faas.trigger, faas.coldstart, faas.invoked_*, etc.)

A workaround could be to define two attribute groups in registry, with the same prefix, where one would be for the resources and the other for semantic attributes. Or we wait for the fix in the tooling and do it properly here.

[trisch-me]

I would vote for a proper workaround assuming we could easily merge it later.
Also as we have discussed before, not all attributes can be easily divided into groups so I would like to have in registry just attributes.

Also as another option - we could merge all open PRs with resource attributes if needed and have a separate issue where we track it to change it later for all. We already do have temporary fix for some other attributes. This will reduce the amount of blocked PRs for now and should be fixed with just 1 PR later.

What do you think @AlexanderWert @joaopgrassi ?

[joaopgrassi]

A workaround could be to define two attribute groups in registry, with the same prefix, where one would be for the resources and the other for semantic attributes.

Also as another option - we could merge all open PRs with resource attributes if needed and have a separate issue where we track it to change it later for all. We already do have temporary fix for some other attributes. This will reduce the amount of blocked PRs for now and should be fixed with just 1 PR later.

Yeah that's what I meant, for those that don't appear in both spans/metrics and resources, we can just port them to the registry as they are today (with res ones having the same prefix but type resource) and the ones who are really appearing we block. At least then we get rid of all the blocked PRs, and with issues we can later track them down once the fix is available.

Either way is fine by me

[trisch-me]

@AlexanderWert do you think I could change it to resource field attributes and then later we would change it to proper value as soon as fix it there?

[trisch-me]

Actually I see we have here again mixed fields, from attributes and from resource, so it will break no matter what we will choose as the type. So we need to have build tools fixed in order to merge this one

[trisch-me]

@joaopgrassi could you please check again?

[github-actions]

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