Decide fate of resource providers

[jack-berg]

#4661 discusses whether this repository is the right home for several components, including opentelemetry-sdk-extension-aws (AWS resource providers), and by extension opentelemetry-sdk-extension-resources.

I'd like to separate out the conversation about the resource providers to this issue to reduce the noise.

The current top candidate is to move resource providers to opentelemetry-java-instrumentation. Resource providers are similar to other instrumentation in the sense that they implement the semantic conventions. And the presence of vendor specific resource providers suggests that this repository is not the right home for these, since opentelemetry-java should not house vendor specific code requiring special knowledge to review.

The challenge to moving to opentelemetry-java-instrumentation is primarily one of artifact coordinates and package names. opentelemetry-sdk-extensions-resources is stable. If we move it to instrumentation, we can either give it new coordinates and package names that align with the pattern of that repo, or retain the existing coordinates and break uniformity. Retaining the same coordinates does mean that we can fully remove the code from this repo, which saves us from having to maintain two copies of the code going forward. (Note, this code is likely to change going forward given the instability of resource semantic conventions.) And if we retain the existing coordinates, then that begs the question of how to name new resource provider artifacts in the future: they can align with the other instrumentation artifacts or with the exception resource provider artifacts.

The other option is to move to opentelemetry-java-contrib, but I can't come up with a convincing argument for that route so I'll abstain. Perhaps someone else can 🙂 .

[trask]

this code is likely to change going forward given the instability of resource semantic conventions

oh, this is an interesting point, that these 2 artifacts are stable, but they are based on unstable semantic conventions

if we move them to the instrumentation repo, I think we'd want to release them as -alpha until the semantic conventions they are based on are stable (my understanding is that this is required by the spec, which is another argument for "abandoning" the old "stable" artifacts)

[jkwatson]

this code is likely to change going forward given the instability of resource semantic conventions

oh, this is an interesting point, that these 2 artifacts are stable, but they are based on unstable semantic conventions

if we move them to the instrumentation repo, I think we'd want to release them as -alpha until the semantic conventions they are based on are stable (my understanding is that this is required by the spec, which is another argument for "abandoning" the old "stable" artifacts)

I believe we marked them as stable because there won't be any binary or source compatibility issues with changing the conventions (since the public APIs won't change). I'm not saying that was correct, but I'm pretty sure that was the reasoning behind it.

[mateuszrzeszutek]

With #4661 (comment) in mind: perhaps we should move the AWS resource providers to the contrib repo (they pretty much require some internal AWS knowledge to maintain), and all OS/runtime/process resource providers to the instrumentation repo?

[jack-berg]

We spoke about this in the 8/25/2022 Java SIG and decided on the following:

• Resource providers for vendor agnostic attribute keys can live in opentelemetry-java-instrumentation, provided that there is a maintainer willing to sponsor inclusion. This includes opentelemetry-sdk-extension-resources which currently lives in this repository, and might include something like the proposed spring boot resource provider if a maintainer is willing to sponsor it.
• Other resource providers, such as those for specific cloud providers should live in opentelemetry-java-contrib. These can still be used easily with the agent by specifying the resource provider jar as an agent extension.

As a result of this, we need to:

• Move opentelemetry-sdk-extension-resources to opentelemetry-java-instrumentation. This is tricky because opentelemetry-sdk-extension-resources is a stable artifact. We've been operating under the assumption that we need to continue to publish stable artifacts for all time to be compliant with semver. However, as discussed in this comment and at the 8/25/2022 SIG, we may not need to. There appeared to be agreement that its acceptable for us to stop publishing artifacts. We discussed easing the update process by changing future versions of the opentelemetry-bom to reference the last published version of artifacts that we stop publishing updates to. I think this is a great option and will investigate feasibility.
• Move opentelemetry-sdk-extension-aws to opentelemetry-java-contrib. This has the same issue with stability as opentelemetry-sdk-extension-resources.