Modifying resources specification to describe capabilities #196
Conversation
toumorokoshi
requested review from
AloisReitbauer,
bogdandrutu,
c24t,
carlosalberto,
iredelmeier,
reyang,
SergeyKanzhelev,
songy23,
tedsuo and
yurishkuro
as code owners
A focus of the specification on the capabilities that should be afforded rather than strict requirements around implementation enable better flexibility to ensure libraries are compatible with the idioms of their corresponding languages. This commit incorporates feedback discussed in open-telemetry#191.
toumorokoshi
force-pushed
the
resources-api-capabilities
branch
from
7a90fc6
to
b95d4b7
Compare
| Creates a new `Resource` that is a combination of labels of two `Resource`s. For | ||
| example, from two `Resource`s - one representing the host and one representing a | ||
| container, resulting `Resource` will describe both. | ||
| Label key namespacing SHOULD be used to prevent collisions across different |
There was a problem hiding this comment.
I wasn't clear on what this line was trying to say. Is this recommending that the labels themselves should be namespaced?
That feels like a recommendation that belongs in a section that describes a Resource object.
There was a problem hiding this comment.
I think Merge API should describe the behavior when collision happened.
Resource concept could describe what's the recommended way of using namespaces, and provide a link to the "predefined schema".
There was a problem hiding this comment.
Thanks! do you have an example or a link of what a predefined schema is? I'm having trouble finding that in the specification.
There was a problem hiding this comment.
Currently there is no central place, and everything was taken from existing OpenCensus.
https://github.com/open-telemetry/opentelemetry-specification/blob/master/work_in_progress/opencensus/StandardResources.md
There was a problem hiding this comment.
got it, thanks! As that gets merged up I'm happy to send a pr if I send see it addressed in a separate one.
…metry#196) A focus of the specification on the capabilities that should be afforded rather than strict requirements around implementation enable better flexibility to ensure libraries are compatible with the idioms of their corresponding languages. This commit incorporates feedback discussed in open-telemetry#191.
…metry#196) A focus of the specification on the capabilities that should be afforded rather than strict requirements around implementation enable better flexibility to ensure libraries are compatible with the idioms of their corresponding languages. This commit incorporates feedback discussed in open-telemetry#191.
A focus of the specification on the capabilities that should be
afforded rather than strict requirements around implementation
enable better flexibility to ensure libraries are compatible with
the idioms of their corresponding languages.
This incorporates feedback discussed in #191.
Updates #165.