Proposal: rename "Resources" to "StaticContext"

[toumorokoshi]

I was running through the propagators, and I think it would be worth considering renaming "Resources" to "StaticContext".

Motivation:

1. Resources effectively are a set of labels that are static for the lifetime of the application. As there is currently no way to represent other values that are static for the lifetime of the application, people will add Resources that have nothing to do with the underlying 'resource' (e.g, environment or version).

2. When one is constructing a set of labels to attach to some piece of telemetry (logs, traces, etc), they will be extracted from the various "Context" objects. by calling this StaticContext, it immediately signals to consumers of labels that this is another pool of values they can retrieve context from. i.e. you could switch from:

• you can pull telemetry tags from SpanContext, DistributedContext, and Resources
  to:

• you can pull telemetry tags from any of the contexts: SpanContext, DistributedContext, and StaticContext.

[jmacd]

There is a working group on this topic: https://gitter.im/open-telemetry/resources-wg

[jmacd]

See also #61

[carlosalberto]

Any update on this?

[bogdandrutu]

This is not the main idea of the Resource as defined initially. Probably we can have 2 things "Resource" + "StaticContext", resource is important to be focus on identifying the source of the telemetry to allow resource correlation between signals (even when not collected from the app, like reading logs from a file).

[toumorokoshi]

I'm curious what the distinction there serves, from a behavioral perspective. The reason I was arguing for this change was because of the behavior and situations by which resources are used: as a way to include additional metadata to all forms of telemetry emitted by a system.

I'm curious if "Resources" is more of a semantic convention, while "StaticContext" is the behavior / system by which it is built off of. But again this is an exploration.

I'm curious about thoughts of where other tags that exist for the lifetime of an application may live, such as "version" or "environment". Would you not add that into something like Resources, to ensure that data propagates to systems like metrics?

[jmacd]

I support the conclusion that resources as they are currently specified are equal to static context. I disagree with the notion that attributes or labels placed into the resources are semantically different than other attributes and labels associated with a spans and metrics.

Suppose I tag an RPC span with "transport:grpc"? It's a resource. Suppose I have another code path that uses "transport:thrift"? It's a resource.

Now suppose I split my binary into two, with one for each transport. Now I'm going to change my telemetry so that all spans from the first process have "transport:grpc" and all spans from the second process have "transport:thrift". There are no semantic differences before and after this change.

I want to remind us of my proposal to support multiple resources: open-telemetry/oteps#78. There, I chose the term "resource scope" as opposed to "static context", but I also like the term "static context" as it is opposed to "dynamic context". In programming languages, a similar concept is "lexical scope", which is how I arrived at the term "resource scope".

[tigrannajaryan]

I am going to close this since the Resource is far too entrenched in Otel to just rename it. Any change in this area will need an OTEP.