SetResourceBuilder is overly restrictive, no way to cooperatively initialize Resources

[Oberon00]

Feature Request

Problem

When initializing a TracerProviderBuilder, some instrumentations might want to add resources (e.g. by interpreting environment variables), e.g. in their AddFooInstrumentation(this TracerProviderBuilder builder) method. Currently the only API for this is SetResourceBuilder, which overwrites all resources that might already exist.

Proposed solution

One nice way would be an AddResourceBuilder API that merges the resources into existing ones. Another option would be to provide a GetResourceBuilder API on the TracerProviderBuilder.

Alternatives considered (currently possible workarounds)

Currently, I can see two ways for any package to work around this:

1. Provide two separate functions for initialization. AddFooInstrumentation(this TracerProviderBuilder builder) which sets up everything except resources, and a separate AddFooResources(this ResourceBuilder builder) which adds just the resources. That makes initialization more complicated as now the user has to call two functions (four if you add the construction of ResourceBuilder and SetResourceBuilder which now the user also has to do themselves) instead of one. It works with multiple cooperating packages though.
2. Allow an additional Resource or ResourceBuilder to be passed as argument to the AddFooInstrumentation function. This is simple, but does not work across multiple packages that all want to add resources.

Additional Context

Note that this is not about adding resources after initialization, but just to have a less awkward API to add resources from multiple sources during initialization to the TracerProviderBuilder.

[Oberon00]

I created PR #3307 which uses a variation of my proposals above: Providing a ConfigureResourceBuilder(Action<ResourceBuilder>) API should be just as flexible as GetResourceBuilder but can be used as succinctly as the existing SetResourceBuilder / the proposed AddResourceBuilder API.

[julealgon]

@cijothomas when will this change be released as a NuGet package update? When is 1.4.0 scheduled to come out?

I'm designing a set of extension methods and would like to have this particular API in place.

EDIT: I found out there is a 1.4.0 milestone that is scheduled for November (I assume to match the release of .NET7). Will this change here have to wait for that, or will it release earlier?

• https://github.com/open-telemetry/opentelemetry-dotnet/milestone/21

[cijothomas]

@cijothomas when will this change be released as a NuGet package update? When is 1.4.0 scheduled to come out?

I'm designing a set of extension methods and would like to have this particular API in place.

EDIT: I found out there is a 1.4.0 milestone that is scheduled for November (I assume to match the release of .NET7). Will this change here have to wait for that, or will it release earlier?

• https://github.com/open-telemetry/opentelemetry-dotnet/milestone/21

We'll be doing 1.4.0-beta.1 this week. Most likely 1.4.0 is coming with .NET 7 timeframe, so Nov this year.