Define resource semantic convention stability and justification #162
Conversation
| *Note: if `aws` was inferred incorrectly on "Acme cloud" previously, that would not be a violation.* | ||
| - Adding new Resource attribute semantic conventions is allowed, however | ||
| existing resource detectors MUST NOT use them, only new detectors would be | ||
| allowed. |
There was a problem hiding this comment.
This last point is a bit vague. What counts as a new detector? If an attribute is added to the K8s resource definition, how would it be handled?
| <!-- semconv k8s.node --> | ||
| | Attribute | Type | Description | Examples | Required | | ||
| |---|---|---|---|---| | ||
| | `k8s.node.name` | string | The name of the Node. | `node-1` | *No* | |
There was a problem hiding this comment.
How does the stability requirement interact with optional attributes?
|
|
||
| Going forward, Resource semantic conventions will be outlined at a "Resource | ||
| detection" level. While users can merge together resource detectors, each | ||
| detector will provide a stable set of Resource attributes and labels. |
There was a problem hiding this comment.
How do resource detectors differ from the current namespacing regime for resource attributes? Is k8s.* a resource detector? Is k8s.cluster.* a resource detector?
| Outline what changes are "safe" to perform for resource semantic conventions | ||
| and which require major version bumps. |
There was a problem hiding this comment.
I am a bit confused as to why we need this document.
I believe that now that starting from 1.4.0 we have Telemetry Schemas, the Schemas defines what changes are safe. If the change is representable as version change in the Schema then it is safe, everything else is unsafe.
| If we assume capabilities of | ||
| [Telemetry Schema conversion](https://github.com/open-telemetry/oteps/pull/161), | ||
| then we can relax some restrictions as follows: |
There was a problem hiding this comment.
So, the previous paragraph assumes no schemas? Schemas are already part of the spec and will be part of 1.4.0 spec, so I do not quite understand why we need to continue evolving the behavior in the schemaless world.
|
There is some related discussion on "identifying vs describing resource attributes" here: open-telemetry/opentelemetry-specification#1298 (comment) |
|
@jsuereth is this otep still relevant/needed? |
|
@tedsuo The problem is relevant the solution is not. I'm closing this draft for now, as I'm crafting up a more targeted proposal for resource conventions for now. |
NOTE: This is incomplete and posted for discussion purposes only.