Remove unreasonable restriction on Sampler's description to be immutable

[yurishkuro]

What are you trying to achieve?

open-telemetry/opentelemetry-go-contrib#936 (comment)

The spec current says:

Description MUST NOT change over time and caller can cache the returned value.

What did you expect to see?

This is unreasonable requirement. First, who is the "caller" who requires this? Second, if this is for efficiency purposes, the caching can be done by the sampler internally when possible. Finally, this restriction fundamentally does not work with samplers that update their sampling policy based on remote control plane.

Proposal

Remove this line from the spec.

[jmacd]

I have questions about the arguments made.

First, who is the "caller" who requires this?

Who is the "caller" who disagrees? I'm interested because in #2047 I have written about what sort of trace completeness guarantees we may expect from a sampler, and the conclusion is that the consumer of a trace ought to know the minimum sampling probability used across the trace. The expectation is that the producer is somehow able to convey this information to the consumer, but we aren't specifying how.

Using the Description() would be one way to learn this information, but it doesn't seem reliable because I would have to probe it very frequently. If you want to specify a mechanism for a span to remember how it was sampled--perhaps a descriptive string--shouldn't that become a span attribute? Then we'll all get something well defined.

Second, if this is for efficiency purposes, the caching can be done by the sampler internally when possible.

How would a Sampler determine when this is possible? It doesn't sound like something for general use.

Finally, this restriction fundamentally does not work with samplers that update their sampling policy based on remote control plane.

You haven't said what you're trying to make work, but it sounds like a fixed description like jaeger_remote:policy_id won't do. Will you log this information periodically?

[yurishkuro]

Who is the "caller" who disagrees?

How is that relevant? The requirement is onerous on the provider (sampler), not on the caller, so the caller needs to provide strong reasons for it.

If you want to specify a mechanism for a span to remember how it was sampled--perhaps a descriptive string--shouldn't that become a span attribute?

100% agree. I think Description has nothing to do with this use case, thus my question. who is the caller who must live or die by this description string being immutable? I see description as purely a debugging / introspection tool, to answer questions like "what's my sampling rate right now?", e.g. from z-pages.

How would a Sampler determine when this is possible? It doesn't sound like something for general use.

Trivially. A sampler whose parameters never change after instantiation can prep the description string once and always return it (iirc some Jaeger samplers did that). A sampler whose parameters can change via control plane can still cache the string upon accepting those change. A sampler whose parameters change continuously cannot satisfy the immutability requirement at all.

You haven't said what you're trying to make work, but it sounds like a fixed description like jaeger_remote:policy_id won't do.

I believe the intention of the description string was to be reflective of the current parameters. If we follow your suggestion, then the string will be simply jaeger_remote:<service_id> which is not especially helpful as introspection tool. All examples in the spec for other samplers show strings that contain both sampler name and its parameters.

[yurishkuro]

Since I didn't see well-argued objections -- #4137