Clarify that resources are immutable #515
Conversation
Oberon00
requested review from
arminru,
bogdandrutu,
c24t,
carlosalberto,
iredelmeier,
jmacd,
reyang,
SergeyKanzhelev,
tedsuo,
tigrannajaryan and
yurishkuro
as code owners
Co-Authored-By: Armin Ruech <armin.ruech@gmail.com>
| [MeterProvider](sdk-metrics.md#meter-sdk). When associated with a `MeterProvider`, | ||
| all `Metrics` produced by any `Meter` from the provider will automatically be | ||
| [TracerProvider](sdk-tracing.md#tracer-sdk) when it is created. | ||
| That association cannot be changed later. |
There was a problem hiding this comment.
Is this sentence OK? There was a discussion in SIG meeting about Kubernetes Pod labels that can change. This would mean that we cannot put them on resources.
There was a problem hiding this comment.
The conversation about resource labels that can change suggests to me that we should support per-Tracer resources as prototyped in open-telemetry/oteps#78. When the pod label changes, you would construct a new scope with the new resources and begin using that tracer. Modifying "static" resources on the fly sounds problematic, to me.
There was a problem hiding this comment.
Not necessary, I can see that pod_labels be logs/events associated with the same immutable Resource. Not saying that scope is not useful but probably not for the pod labels example.
There was a problem hiding this comment.
Actually, having global events sounds like a useful idea. You should make an issue for that.
There was a problem hiding this comment.
Also these events are more or less some type of "time-series" being associated with the time when they change. Not trying to design the solution here, but just some "food for thought" :)
| [MeterProvider](sdk-metrics.md#meter-sdk). When associated with a `MeterProvider`, | ||
| all `Metrics` produced by any `Meter` from the provider will automatically be | ||
| [TracerProvider](sdk-tracing.md#tracer-sdk) when it is created. | ||
| That association cannot be changed later. |
There was a problem hiding this comment.
The conversation about resource labels that can change suggests to me that we should support per-Tracer resources as prototyped in open-telemetry/oteps#78. When the pod label changes, you would construct a new scope with the new resources and begin using that tracer. Modifying "static" resources on the fly sounds problematic, to me.
|
@open-telemetry/technical-committee (@bogdandrutu): As discussed in yesterday's SIG Spec call, can we please merge this? |
The spec did never explicitly say that resources are immutable. It IMHO did so implicitly, as there are create+merge operations but no set operation. This PR makes immutability explicit.
All implementations that I know of already have immutable resources, so this should hopefully really just be a clarification.