-
Notifications
You must be signed in to change notification settings - Fork 164
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
Configuration proposal #225
Configuration proposal #225
Conversation
This OTEP is the result of the Configuration working group. See open-telemetry/opentelemetry-specification#2920 for additional details. cc @MrAlias @jack-berg Signed-off-by: Alex Boten <[email protected]>
c9fb1a5
to
86b65ac
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Incredibly exciting change that would massively improve our ability to easily configure SDKs internally. Thank you for proposing this!!
Signed-off-by: Alex Boten <[email protected]>
Left a pair of comments but overall LGTM. One thing I'm curious about though, is how to individually enable/disable instrumentation libraries (which currently is exposed by both Java and DotNet auto instrumentation), e.g. cc @pellared |
Signed-off-by: Alex Boten <[email protected]>
@open-telemetry/dotnet-instrumentation-maintainers PTAL |
Co-authored-by: Reiley Yang <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Co-authored-by: Reiley Yang <[email protected]>
Initial followup to [OTEP #225](open-telemetry/oteps#225). This lays the initial groundwork for file configuration in the specification. There are placeholders TODOs for many various followup tasks. Additional work is also needed to figure out how to merge [SDK Configuration](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-configuration.md), [SDK Environment Variables](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md) and file configuration into a cohesive story. This PR proposes the configuration schema live in `opentelemetry-specification/specification/configuration/schema/`, which implies that at some point additional build steps will be needed to confirm changes to the schema are valid and allowed. cc @MrAlias, @codeboten
* Configuration proposal This OTEP is the result of the Configuration working group. See open-telemetry/opentelemetry-specification#2920 for additional details.
Part of incorporating [OTEP #225](open-telemetry/oteps#225) into the specification. Followup to #3360.
Part of incorporating [OTEP #225](open-telemetry/oteps#225) into the specification. Followup to #3437. The adds the YAML file format, and leaves an open TODO for the JSON format discussed in the original OTEP. It also define environment variable substitution. IMO its necessary to define environment variable substitution at the same time as file format because they interact in ways that aren't immediately obvious and need to be prototyped. The opentelemetry-java implementation of file configuration already accepts YAML encoding and performs environment variable substitution as described in this PR. It does not support JSON, and I don't think we should unless there is good reason. I omitted the JSON file format because I don't know of any prototypes that permit it. We should add JSON once a language implements it and explores how environment variable substitution works with JSON.
Part of incorporating [OTEP #225](open-telemetry/oteps#225) into the specification. Followup to #3744. This defines how file configuration works with custom SDK extension components (Samplers, Exporters, etc). It defines the concept of a Component Provider: - Component providers are registered with the type of extension component they provide and a name. Component providers are registered automatically or manually based on what is idiomatic in the language. - Component providers have a Create Plugin method, which passes configuration properties as a parameter and returns the configured component - When Create is called to interpret a file configuration model, and it comes across a reference to a extension component which is not built-in, it invokes Create Plugin on the corresponding component provider. If no corresponding component provider exists, or if Create Plugin returns an Error, Create returns an error. Prototype implementation in java here: open-telemetry/opentelemetry-java-examples#227 cc @open-telemetry/configuration-maintainers
* Configuration proposal This OTEP is the result of the Configuration working group. See open-telemetry/opentelemetry-specification#2920 for additional details.
* Configuration proposal This OTEP is the result of the Configuration working group. See open-telemetry/opentelemetry-specification#2920 for additional details.
* Configuration proposal This OTEP is the result of the Configuration working group. See open-telemetry/opentelemetry-specification#2920 for additional details.
Initial followup to [OTEP open-telemetry#225](open-telemetry/oteps#225). This lays the initial groundwork for file configuration in the specification. There are placeholders TODOs for many various followup tasks. Additional work is also needed to figure out how to merge [SDK Configuration](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-configuration.md), [SDK Environment Variables](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md) and file configuration into a cohesive story. This PR proposes the configuration schema live in `opentelemetry-specification/specification/configuration/schema/`, which implies that at some point additional build steps will be needed to confirm changes to the schema are valid and allowed. cc @MrAlias, @codeboten
* Configuration proposal This OTEP is the result of the Configuration working group. See open-telemetry#2920 for additional details.
…#3437) Part of incorporating [OTEP open-telemetry#225](open-telemetry/oteps#225) into the specification. Followup to open-telemetry#3360.
…telemetry#3744) Part of incorporating [OTEP open-telemetry#225](open-telemetry/oteps#225) into the specification. Followup to open-telemetry#3437. The adds the YAML file format, and leaves an open TODO for the JSON format discussed in the original OTEP. It also define environment variable substitution. IMO its necessary to define environment variable substitution at the same time as file format because they interact in ways that aren't immediately obvious and need to be prototyped. The opentelemetry-java implementation of file configuration already accepts YAML encoding and performs environment variable substitution as described in this PR. It does not support JSON, and I don't think we should unless there is good reason. I omitted the JSON file format because I don't know of any prototypes that permit it. We should add JSON once a language implements it and explores how environment variable substitution works with JSON.
…lemetry#3802) Part of incorporating [OTEP open-telemetry#225](open-telemetry/oteps#225) into the specification. Followup to open-telemetry#3744. This defines how file configuration works with custom SDK extension components (Samplers, Exporters, etc). It defines the concept of a Component Provider: - Component providers are registered with the type of extension component they provide and a name. Component providers are registered automatically or manually based on what is idiomatic in the language. - Component providers have a Create Plugin method, which passes configuration properties as a parameter and returns the configured component - When Create is called to interpret a file configuration model, and it comes across a reference to a extension component which is not built-in, it invokes Create Plugin on the corresponding component provider. If no corresponding component provider exists, or if Create Plugin returns an Error, Create returns an error. Prototype implementation in java here: open-telemetry/opentelemetry-java-examples#227 cc @open-telemetry/configuration-maintainers
* Configuration proposal This OTEP is the result of the Configuration working group. See open-telemetry/opentelemetry-specification#2920 for additional details.
* Configuration proposal This OTEP is the result of the Configuration working group. See open-telemetry/opentelemetry-specification#2920 for additional details.
This OTEP is the result of the Configuration working group. See open-telemetry/opentelemetry-specification#2920 for additional details.
cc @MrAlias @jack-berg
On-going prototypes: