resource terminology and API #56
Conversation
SergeyKanzhelev
requested review from
AloisReitbauer,
bogdandrutu,
c24t,
carlosalberto,
iredelmeier,
songy23,
tedsuo and
yurishkuro
as code owners
| When associated with the `SpanData` explicitly for out-of-band spans - | ||
| `Resource` that is set on `Tracer` MUST be ignored. | ||
|
|
||
| **TODO**: explain how resource is associated with metrics. |
There was a problem hiding this comment.
Let's add it later. I don't want to introduce an empty metrics-api.md document in this PR.
| Second, by merging two `Resource`s into a new one. The method [Merge](#merge) is | ||
| used when a `Resource` is constructed from multiple sources - metadata API call | ||
| for the host and environment variables for the container. So a single `Resource` | ||
| will contain labels for both. |
There was a problem hiding this comment.
What is the reason for doing this on resource level (extending API surface with the Merge() function) instead of doing the merge on the collection of labels?
There was a problem hiding this comment.
Merge has a logic on how to deal with empty or duplicate values. In OC it was also doiung a merge of a field type.
I agree it's not much to justify this API today. But it is what we have in Java reference API. Do you want to track it as a "API feedback issue"? Please file an issue
There was a problem hiding this comment.
Merge has a logic on how to deal with empty or duplicate values. In OC it was also doiung a merge of a field type.
That's just an artifact of having a merge in the first place, no? If it was up to the user to provide a map of labels, then they would have to deal with duplicates, not the spec. And the type would only be specified once.
* resource terminology and API * addressed code review comments
…h-releases Strengthen rules for GitHub Releases
Since this OTEP has been thoroughly discussed before entering the "proposed" stage, it should be ready for approval already.
Since this OTEP has been thoroughly discussed before entering the "proposed" stage, it should be ready for approval already.
* resource terminology and API * addressed code review comments
#36 and #47