Clarify/relax required resource attributes.

[Oberon00]

Fixes #1346.

Depends on #1345 ✔️ .

Changes

Clarify that it is enough to add required resource attributes when the resource is associated with something to the default resource. We do not need to somehow patch the attribute on every (temporary) resource object created by the user.

Related Java issues (see linked PRs there): open-telemetry/opentelemetry-java#2298

EDIT on 2020-12-19: I forgot to update this PR description to match the changes from 1698fd0 (2020-12-17). Done now.

[yurishkuro]

The implication is that each provider would be responsible for setting those required attributes to default values. Should there be some framework for enriching resources that providers can share, to avoid duplication?

Also, do we document default fallback values for all required attributes? Service name alone too a number of iterations.

[Oberon00]

Something was weird here with the auto-requested reviews (there seem to have been none?) so I manually requested reviews now.

[jkwatson]

This is a good clarification. I think it should also be highlighted in the referenced document [semantic_conventions/README.md#attributes-with-default-value)]

[Oberon00]

Since I have no approvals yet anyway, I reworked this again to not always force the attributes into the Resource. If this is too lenient, I can go back to requiring setting the attributes at time of association with TracerProvider/MeterProvider (see state at f65800a).

[jkwatson]

thanks! much cleaner/clearer than what was previously specified.

[anuraaga]

Thanks!

[arminru]

Thanks! Please don't forget about the changelog 🙂

[Oberon00]

Done. BTW the new/updated distinction seems to be lost currently.

[jonatan-ivanov]

I'm not sure this is the right place for this question but why this property is called service.name? Should not this be a little more general, e.g.: application.name (e.g.: in case of a thick client)?

[carlosalberto]

Not a strong feeling, but I'd vow for 3a as it's the simplest one (and should work just fine).

[carlosalberto]

@jonatan-ivanov In order to not lose focus here, would you mind opening an issue with this question? Or even better, come to the Spec SIG meeting on Tuesday, 8AM Pacific ;)

[carlosalberto]

@open-telemetry/specs-approvers Please review the latest iteration. Once we get 1-2 more reviews we are good to go (usually we need less reviews, but this being a tricky one, I'd rather have more eyes on it). Else, we will merge in the next days ;)

[yurishkuro]

this is not clear to me.

The SDK MUST provide access to a Resource

provide access to whom? because later it says

This resource MUST be associated with a TracerProvider or MeterProvider

associated by whom?

Are we saying that SDK must expose an API like getDefaultResource() that the user MUST call and then pass to provider? What if another resource is passed, not the default one, and thus the required attributes are still not available?

[Oberon00]

The SDK MUST provide access to a Resource

provide access to whom? because later it says

As a public API.

This resource MUST be associated with a TracerProvider or MeterProvider

associated by whom?

By the Tracer/MeterProvider implemenentation. For that, a public API would not be necessary, but it does not hurt that case and is very useful if exporters want to access it, e.g. to get a fallback service.name.

Are we saying that SDK must expose an API like getDefaultResource()

Yes

that the user MUST call and then pass to provider?

No, we do not place MUST requirements on the user here. See my above answer in this comment.

What if another resource is passed, not the default one, and thus the required attributes are still not available?

Then whoever needs these attributes needs to fall back to the default resource. This could be done e.g. by explicitlyPassedResource.Merge(defaultResource).get(theAttributeNeeded).

I don't think this addresses the underlying cause of always having service name, given current wording

[Oberon00]

As discussed in the spec meeting: If we change the order of arguments of Merge (i.e. last value wins like everywhere else in OTel), this PR would offer better UX.

[anuraaga]

last value wins++! I always have to double-take when using Resource.merge

[Oberon00]

I created a separate PR for the Resource.Merge change: #1345. I also created issue #1346 for tracking.

[carlosalberto]

@open-telemetry/specs-approvers I will merge this by EOD, FYI ;) (unless there's some late feedback against, etc)

[carlosalberto]

@Oberon00 Please rebase so we can finally merge this.