Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify that resources are immutable #515

Merged
merged 6 commits into from
Mar 27, 2020
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 11 additions & 8 deletions specification/sdk-resource.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,13 +13,15 @@ with closed source environments. The SDK MUST allow for creation of `Resources`
for associating them with telemetry.

When used with distributed tracing, a resource can be associated with the
[TracerProvider](sdk-tracing.md#tracer-sdk). When associated with a
`TracerProvider`, all `Span`s produced by any `Tracer` from the provider will
automatically be associated with this `Resource`.

When used with metrics, a resource can be associated with the
[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.
Copy link
Member Author

@Oberon00 Oberon00 Mar 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, having global events sounds like a useful idea. You should make an issue for that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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" :)

When associated with a `TracerProvider`,
all `Span`s produced by any `Tracer` from the provider MUST be associated with this `Resource`.

Analogous to distributed tracing, when used with metrics,
a resource can be associated with the [MeterProvider](sdk-metrics.md#meter-sdk).
Oberon00 marked this conversation as resolved.
Show resolved Hide resolved
When associated with a `MeterProvider`,
all `Metrics` produced by any `Meter` from the provider will be
associated with this `Resource`.

## Resource creation
Expand Down Expand Up @@ -67,7 +69,8 @@ attributes"](data-semantic-conventions.md) that have prescribed semantic meaning

## Resource operations

In addition to resource creation, the following operations should be provided:
Resources are immutable. Thus, in addition to resource creation,
arminru marked this conversation as resolved.
Show resolved Hide resolved
only the following operations should be provided:

### Retrieve attributes

Expand Down