What are you trying to achieve?
For SDKs, make the environment variable substitution (also known as interpolation) an opt-in feature controlled via a OTEL_CONFIG_INTERPOLATE boolean env var.
Additional context.
The env var substitution logic is complex.
Requiring each SDK to [correctly] implement it may take a long time. Personally, I also think that because of the complexity of the problem each language should have fuzz tests for the parsing logic.
Making a different substitution logic in SDKs and Collector may result in a bad user experience. Getting different results for the same config in different OTel components can cause a lot of user frustration.
Users can use envsubst or a tool provided by OTel like validator (probably would be good to rename it) instead of doing it via the SDK.
The environment variable substitution as part of the SDK is a blocker only for environments where the ecosystems cannot bundle in a binary specific to a particular platform / architecture. However, the same can be said for the Collector and some missing functionalities in the SDKs.
Making environment variable substitution as an opt-in feature should speedup the configuration development that should satisfy most of the users without shutting the door for future improvements.
Related PR where this idea has been originally proposed: #4375
What are you trying to achieve?
For SDKs, make the environment variable substitution (also known as interpolation) an opt-in feature controlled via a
OTEL_CONFIG_INTERPOLATEboolean env var.Additional context.
The env var substitution logic is complex.
Requiring each SDK to [correctly] implement it may take a long time. Personally, I also think that because of the complexity of the problem each language should have fuzz tests for the parsing logic.
Making a different substitution logic in SDKs and Collector may result in a bad user experience. Getting different results for the same config in different OTel components can cause a lot of user frustration.
Users can use
envsubstor a tool provided by OTel likevalidator(probably would be good to rename it) instead of doing it via the SDK.The environment variable substitution as part of the SDK is a blocker only for environments where the ecosystems cannot bundle in a binary specific to a particular platform / architecture. However, the same can be said for the Collector and some missing functionalities in the SDKs.
Making environment variable substitution as an opt-in feature should speedup the configuration development that should satisfy most of the users without shutting the door for future improvements.
Related PR where this idea has been originally proposed: #4375