Opentelemetry-specification: Revert #1043 (Third Party Propagators location)

[carlosalberto]

We had a previous issue (and a fair amount of time spent discussing it - taking a pair of weeks) that ended up in the decision (with the help of a the language maintainers) to NOT maintain third party propagators as part of OpenTelemetry.

1043 is NOT trivial as it has a related solved issue/PR and needs to be reverted - _then_ we may discuss this again and decide if/why we really need this.

cc @dyladan
cc @SergeyKanzhelev

[SergeyKanzhelev]

I read the issue and PR and I didn't get an impression there is a controversy. Perhaps it was discussed on the meeting and not reflected on the issue. Can you summarize the controversy here? How the "encouraged" language is different from "can"?

[carlosalberto]

@SergeyKanzhelev This was an intermediate decision (as I said, this decision took weeks and weeks). Yes, it was definitely discussed one more time yet after and that's why we ended up changing that initial agreement that @mtwo mentioned (the discussion/changes can show that).

The controversy is that OTel maintainers do not want to maintain third party propagators and this resolution took a little while to reach.

How the "encouraged" language is different from "can"?

IMHO this will open a potential struggle between Maintainers and third parties when it comes to where to host the propagators (why yes here, why no there). I'd prefer to have the things clear.

In any case, if Maintainers decide this change is fine, I'm all up for it, but let's do it in a proper way and discuss this again with the Maintainers.

[SergeyKanzhelev]

I share your worries. I said on PR it's uncontroversial and merged as the PR didn't change anything semantically - encourage language changed to can.

If the decisions would be to evict those from SDK, the change would be with the same reasoning I added mention that propagators needs to be self contained so people can use it with SDK without the need to import entire vendor's set of packages like exporters.

So if discussions are still ongoing, it will be a semantical change to what was written, but additive to what I have added. Is it something will be discussed next Tuesday meeting?

[carlosalberto]

@SergeyKanzhelev Let's definitely discuss this next week. Meanwhile, I will keep this issue open.

[SergeyKanzhelev]

thinking about it - maybe maintainers meeting would be even more appropriate for this. Understanding the balance between what maintainers willing to support and how easy it is for end users to consume.

[carlosalberto]

SGTM

[mtwo]

Following up from the maintainers meeting. There are three types of propagators:

Fully open standards

• W3C
• B3

Platform-specific standards

• AWS X-Ray header
• Google Cloud-Trace-Context (being deprecated)

Proprietary headers

• Dynatrace
• New Relic
• Etc.

It is clear that fully open standards should be in the main SDK packages / repos, and that proprietary headers should not be. This discussion is about whether we should place platform-specific standards in the main repositories or contrib / external repositories.

From the discussion at the maintainers meeting, we will not put platform-specific context formats in the primary SDK repositories. They can exist within official contrib repositories, vendor-specific repositories, or anywhere else.

[mtwo]

@alolita will take the action to formalize this

[SergeyKanzhelev]

primary SDK repositories

Does primary mean SDK or it also includes -contrib?

[mtwo]

primary SDK repositories

Does primary mean SDK or it also includes -contrib?

Just added this to clarify: They can exist within official contrib repositories, vendor-specific repositories, or anywhere else.

[andrewhsu]

from the issue triage mtg today, decision on this issue will affect go sig because imports strongly tied to repos.

@alolita talked about this and your name came up. would you be able to provide a draft for this issue by monday? quick action on this will give time for go sig to adjust. else @mtwo will do this on monday.

[carlosalberto]

FYI, I will prepare a PR to revert the PR (while keeping @SergeyKanzhelev's improvements) and then @alolita will be able to provide the follow up on the Platform Specific Propagators ;)

[MrAlias]

Is this still happening? Moving the location of where our propagators live in the Go repos will be a breaking change. If want to do this can we resolve this soon?