Review faas invoked_name, invoked_provider, invoked_region attributes

[lmolkova]

I see here a duplication of data for invoked_name, invoked_provider and invoked_region. Was it needed because of strict separation between resource and not resource attributes? Should we remove it now and replace with original fields as we are going into removing this restriction in build tools?

Originally posted by @trisch-me in #525 (comment)

Currently we have notes for these fields as following:

`invoked_name`  SHOULD be equal to the `faas.name` resource attribute of the invoked function.

`invoked_provider ` SHOULD be equal to the `cloud.provider` resource attribute of the invoked function.

`invoked_region` SHOULD be equal to the `cloud.region` resource attribute of the invoked function.

[arminru]

I don't think this was added due to tooling restrictions but rather because the semantics are intended to be different.

Consider the following example:

  Service A           --invokes-->     Function B
------------------------------------------------------------
Resource as reported by B:
                                       faas.name=B
                                       cloud.provider=MyCloud
                                       cloud.region=World
------------------------------------------------------------
Span as reported by A:
  faas.invoked_name=B
  faas.invoked_provider=MyCloud
  faas.invoked_region=World

If both resource and span attributes would be flattened (particularly when exporting in a non-OTLP format or as OTLP to a back-end that does not distinguish them) this would cause ambiguity if the same attribute keys were used. In these cases, the span created by Service A with a span attribute cloud.provider=MyCloud would make Service A appear to be hosted there (as if it was its own resource), which might not be the case since it's instead actually describing the invoked Function B.

Service A could also itself be a function and have its own faas.name/cloud.provider/cloud.region resource attributes set and then they would even clash upon flattening.

[lmolkova]

great point @arminru!

BTW I think it's where @trisch-me embed proposal could help.
With it we could do something like

- id: faas
  prefix: faas
  attributes:
    - embed: cloud.provider

and it'd result in faas.cloud.provider attribute getting all it's properties and members from the original cloud.provider.
I think naming could be improved, but I guess we could also support custom naming when embedding attributes.

[trisch-me]

Thanks @arminru for clarification, this makes sense now. So it's just a guidance on what to put to the attributes values.

I'll close the issue then. Please feel free to re-open if needed