You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently autoprop module only supports setting the propagator either by passing actual propagators objects or via environment variable OTEL_PROPAGATOR.
This limits consumers of the module to expose these settings as external configuration strings.
For example OTel Collector using this autoprop can only configure the autoprop module either by introducing
it's own configuration semantics and later convert the configuration strings into propagator objects to pass them to the autoprop or
Set the environment variables from withing the process by taking the values as configuration strings.
But having an api that takes in a string with values equivalent to what gets passed in OTEL_PROPAGATOR let consumers expose the sdks settings as configuration.
Would adding a function like the following accomplish this request?
// RetrieveTextMapPropagator returns a TextMapPropagator composed from the passed names.// Each name must match an already registered TextMapPropagator (see the RegisterTextMapPropagator function for more information), or a default (tracecontext, baggage, b3, b3multi, jaeger, xray, or ottrace).//// If "none" is passed, or no names are provided, the returned TextMapPropagator will be a no-operation implementation.//// An error is returned for any un-registered names.// The remaining, known, names will be used to compose a TextMapPropagator that is returned with the error.funcRetrieveTextMapPropagator(names...string) (propagation.TextMapPropagator, error) {
/* implementation */
}
Background
Currently autoprop module only supports setting the propagator either by passing actual propagators objects or via environment variable OTEL_PROPAGATOR.
This limits consumers of the module to expose these settings as external configuration strings.
For example OTel Collector using this autoprop can only configure the autoprop module either by introducing
it's own configuration semantics and later convert the configuration strings into propagator objects to pass them to the autoprop or
Set the environment variables from withing the process by taking the values as configuration strings.
But having an api that takes in a string with values equivalent to what gets passed in OTEL_PROPAGATOR let consumers expose the sdks settings as configuration.
see open-telemetry/opentelemetry-collector#5572
The text was updated successfully, but these errors were encountered: