profile: drop duplicate field in message Profile

[florianl]

The message Profile contains two fields of type opentelemetry.proto.common.v1.KeyValue, attribute_table and attributes. Both fields are intended for the same use. Therefore drop the later one.

ping @open-telemetry/profiling-maintainers @jhalliday

[jhalliday]

yes, not actually duplicates. The attributes_table is there to be referenced by fields of attributes in other places as a de-duplication / size reduction measure, whereas the attributes field is for things that belong directly to the profile itself. It would be correct, though not especially useful, to make the attributes field a repeated int indexing into the attributes table, but removing it entirely is not appropriate.

[florianl]

Thanks for the feedback. The differences between attribute_table and attributes were not clear, so that gave me the impression of a duplicate field. To address your feedback, I have added attribute_indices with bcfb44e for the global attributes in message Profile, that can reference into attribute_table.
This should help differentiating the attributes while having only a single attribute_table which also helps to deduplicate elements.

[jhalliday]

@dmathieu does this have the potential to cause headaches in the collector? Adding attributes to the 'top level' entity in a given signal type seems like one of the most common mutations in the collector pipeline use cases and I think all the others use common.v1.KeyValue and hence probably have shared pdata golang types/code for doing so. Are we adding undue complexity here if profiles works a different way?

[dmathieu]

Processors should be able to get a command to "add an attribute to a profile/sample", and have that turned into the proper append/find in the attributes table, and indices.
So I don't think it's so much of an added complexity.

It's true that the entirety of these mapping tables are pretty unique to profiles, and none of the other signals use it though, making profiles rather a snowflake.

[lmolkova]

We'd like to cut a release before holidays, draft PR - #611

Should we try to get this PR in since it seems to be pretty close, @open-telemetry/profiling-approvers ? I can wait a day or two.

[felixge]

We'd like to cut a release before holidays, draft PR - #611

Should we try to get this PR in since it seems to be pretty close, @open-telemetry/profiling-approvers ? I can wait a day or two.

I think this is ready to go from our perspective. We just need @open-telemetry/spec-sponsors approval 🙇