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

Request to expose string based configuration in autoprop module. #2590

Closed
pavankrish123 opened this issue Jul 20, 2022 · 2 comments · Fixed by #2593
Closed

Request to expose string based configuration in autoprop module. #2590

pavankrish123 opened this issue Jul 20, 2022 · 2 comments · Fixed by #2593
Assignees
Labels
area: instrumentation Related to an instrumentation package enhancement New feature or request

Comments

@pavankrish123
Copy link

pavankrish123 commented Jul 20, 2022

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

  1. it's own configuration semantics and later convert the configuration strings into propagator objects to pass them to the autoprop or

  2. 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

@MrAlias
Copy link
Contributor

MrAlias commented Jul 20, 2022

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.
func RetrieveTextMapPropagator(names ...string) (propagation.TextMapPropagator, error) {
	/* implementation */
}

@pavankrish123
Copy link
Author

Yes the api would do just fine. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: instrumentation Related to an instrumentation package enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants