Replies: 4 comments
-
|
File configuration is a new feature not a requirement. We should not remove environment variable functionality, which is widely used in manual instrumentation and extremely required for auto-instrumentation simply to add another feature. Removing environment variable functionality would be a gigantic breaking change that would severely affect all Azure customers. Assuming I understand the wording of the proposals correctly, I strongly recommend Proposal 1. This would keep all env var defaulting behavior in the sdk, but allow for environment variable substitution in the file configuration. This is the best of all words:
It seems the only supposed downside to Proposal 1 is that users would have to specify in the file how they want env vars to be used. But, that seems appropriate and almost inevitable to me given the scale of file configuration (multiple of every component). This approach is the most user friendly, clear, and customizable. Proposal 2 seems like the worst of all words to me. It would break customers, require extensive development in each language, and leave a confusing and ill-defined ruleset for any existing and future env var configuration. I am not sure I understand Proposal 3 completely. Is it basically that there would be a new and separate set of env vars just for file configuration overrides? Would this leave the existing env vars functionality completely intact? Finally, what about exploring the option of providing the entire yaml/json config in the value of an env var like OTEL_CONFIGURATION or something as an option. Then literally everything could be codelessly overwritten. I've seen config options like that in cloud services/ |
Beta Was this translation helpful? Give feedback.
-
|
Open to discussing this again in this week's SIG. |
Beta Was this translation helpful? Give feedback.
-
|
I think first we have to clearly define what the intentions of this effort is to begin with. I think if this effort is to define a separate new FEATURE, to be able to instantiate code so that users can avoid writing boilerplate code, we are free to define whatever mechanism we want (whether it be overriding or substituting environment variables). However, we need to get extreme clarity that this is a FEATURE, and not a mechanism to change the existing behavior of our API/SDK, especially as it relates to configuration of components via environment variables. If this is a way to eventually introduce configuration of the api/sdk, this is a much more serious discussion and I prefer to not break any existing behavior and as well, whatever mechanism we define we must follow the spec. On another note, if we DO treat this as a completely separate feature, we must make sure to explicitly differentiate it from FILE CONFIGURATION. Maybe we should even name this something else (@ocelotl proposed something called "Pipeline"). As well, we must ensure that it doesn't cause confusion for users when we DO eventually introduce FILE CONFIGURATION. At that point, "pipeline configuration" or whatever this feature will be called will already be introduced, so users will already have some sort of "config file" to generate boiler plate code. We must ensure that users are not confused and that these files are used for different purposes. |
Beta Was this translation helpful? Give feedback.
-
|
I have changed my approach quite a bit, it is described here now: https://gist.github.com/ocelotl/c1dc0c9e3e1d9ad623bc393ed9fb0e36 |
Beta Was this translation helpful? Give feedback.
-
The OpenTelemetry community has been discussing here what should we do with the current environment variables and the new proposal for a configuration model that would use YAML files (an example here).
Right now we have 3 proposals that are more or less well defined, find them here under the Feb 5, 2024 entry.
@jack-berg has drafted a document that explains the third proposal in more detail.
I implemented the current Python configuration prototype here. Right now this prototype does not implement any of these proposals (it just implements environment variable substitution in the configuration file, which can go or stay depending on what decision we make on this issue).
Python contributors, please let us Python maintainers know your opinions on this issue by adding them to this discussion.
Just a disclaimer, my position on this issue can be found in the links above, I won't add more explanation for my position here in order to minimize bias for the readers of the proposals.
Beta Was this translation helpful? Give feedback.
All reactions