processcontext: add ProcessContext message from OTEP 4719

[ivoanjo]

As open-telemetry/opentelemetry-specification#4719 looks to be merged soon, it came up as we were implementing this spec in the OTel eBPF Profiler
(open-telemetry/opentelemetry-ebpf-profiler#1181) that it'd be nice to stop copy-pasting the process_context.proto and it's time to add it to the proper place.

This is my first contribution to this repo so please do point out if I missed something! I didn't touch the collector parts since this message is not expected to be processed by the collector directly.

[felixge]

LGTM

[felixge]

NIT: Is this verbose description of the attribute semantics meant to indicate that the requirements here are different from the ResourceProfiles message?

[ivoanjo]

requirements here are different

No, afaik they should be the same as we carry in resource profiles. Do you think it would be clearer to add something along the lines of "A reader such as the OTel eBPF profiler is expected to carry this info in the ResourceProfiles message"?

[felixge]

I was mostly thinking that the comments for this field should be the same across all messages that use it in the same way.

[ivoanjo]

Ack! In ec83a05 I've tweaked the comment to match profiles.proto.

In hindsight this was a bit of "I'm looking but I'm not actually seeing it anymore" -- the previous comment had evolved from a time where we had attributes, not a resource directly, and was lifted from resource.proto, but doesn't make a lot of sense now that we embed the whole resource as a nested message.

[rogercoll]

🎉

[tigrannajaryan]

I would like to discuss if this is the right repo for this proto.

Currently the repo description is "OpenTelemetry protocol (OTLP) specification and Protobuf definitions" and I do not think what is being added is part of OTLP.

We have a few options:

• Use a separate repo
• Explicitly extend the purpose of the repo
• Clarify that this is indeed part of OTLP (how?)

[jsuereth]

We discussed in the specification meeting.

A few thoughts:

• This is called opentelemtery-proto not OTLP repository - it seems to imply this should contain any proto definition, not just OTLP. We should update the name or readme if we think this is wrong.
• This is a new protocol of a sort, but it is tightly tied to OTLP - to the point that versioning it together with OTLP is likely desired.
• We believe this is not a 1-way door - we can easily extract out the process context protocol to a separate repo prior to stability.

@florianl / @ivoanjo - should we open an issue to track this decision and mark it as a blocker to stabilizing the process-context protocol?

[ivoanjo]

+1 I think it makes a lot of sense to make extra sure we're happy with this decision (or change it) prior to stabilizing it, and for now experiment with having it here during development and check how useful/not useful that turns out.

[reyang]

We discussed in the specification meeting.

A few thoughts:

• This is called opentelemtery-proto not OTLP repository - it seems to imply this should contain any proto definition, not just OTLP. We should update the name or readme if we think this is wrong.
• This is a new protocol of a sort, but it is tightly tied to OTLP - to the point that versioning it together with OTLP is likely desired.
• We believe this is not a 1-way door - we can easily extract out the process context protocol to a separate repo prior to stability.

@florianl / @ivoanjo - should we open an issue to track this decision and mark it as a blocker to stabilizing the process-context protocol?

Some additional context:

1. According to https://github.com/open-telemetry/opentelemetry-proto?tab=readme-ov-file#opentelemetry-protocol-otlp-specification, this repository intends to focus on OTLP. This can also be confirmed by looking at the contents under https://github.com/open-telemetry/opentelemetry-proto/tree/main/docs. The "proto" part of the repository name seems to indicate "protocol" rather than "*.proto files".
2. If we decided to use this repository to only hold proto definitions, we would need to move the OTLP docs to a different place, and update the repo README file to clarity the intention.
3. If we decided to use this repository to only hold OTLP related contents (proto definitions and spec docs), we can either do nothing or rename the repo (e.g. to opentelemetry-protocol or otlp) to avoid the confusion.
4. If we decided to use this repository to hold both the OTLP related contents and other proto definitions, I feel this is going to create more problems in the future.

[tigrannajaryan]

• This is called opentelemtery-proto not OTLP repository - it seems to imply this should contain any proto definition, not just OTLP. We should update the name or readme if we think this is wrong.

That's only the repo name. The content of the repo currently is strictly OTLP. The README talks about OTLP, the "docs" directory is all about OTLP.

I do not mind hosting other *.proto files in this repo, as the name of the repo implies. But if we want to do that at least we must update the README and somehow reflect that "docs" are only about OTLP.

[ivoanjo]

In my (very humble) opinion, the really nice plus of having it in this repo is making it really easy to consume/distribute this protobuf message definition.

Having it in a whole different location would mean something along the lines of:

• duplicating some of that machinery
• recreating it everywhere where we want to have it
• copy pasting a bunch of things around (bleh)

It sounds like there's some openness to keep it in this repo if we update the docs to avoid the confusion of "is this just OTLP or what?; I might be slow over the next few days (flying to Japan to speak at RubyKaigi conference!) but I'll push an update to this PR to update docs ASAP so y'all can see if that direction looks like it's good or not :)

[florianl]

Following the repo's description "OpenTelemetry protocol (OTLP) specification and Protobuf definitions" it reads to me as it should not be limited to OTLP only. But I also agree, that some parts of the README should be rephrased to clarify this point.

On the practical side, having this here means the OTel ecosystem can benefit from it without hunting for it in another place. Plus, spinning up a whole separate repo seems like overkill, as it would duplicating CI, releases and maintenance overhead.

Since these proposed changes are marked as development, we're not committing to anything forever. If down the road it makes sense to move it or remove it, we still can do that.