-
Notifications
You must be signed in to change notification settings - Fork 896
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
Definition of Boolean for Environment Variables #2729
Comments
I would suggest this be the only acceptable true value, and not just one possible option.
I already brought it up in the other PR but I think this is a point of potential confusion. Having SDKs from different languages behave differently makes it more difficult to configure polyglot environments.
The only recommendation I have here is that all environment variables should be named such that |
I agree with this. I'm wondering whether, for the sake of completeness, any SIG has ever supported a different value for booleans at all? |
I support a single boolean value "true", with emphasis on @dyladan's point: all environment variables should be named such that false is the expected default behavior. |
We may even want to go so far as to log a warning when a boolean env var has any value that isn't |
Should we also define the type for all the rest of environment variables? I mean, should we specify "this variable is to be interpreted as an int, this one as a string, this one as a float, this one as a bool", etc.? |
@ocelotl We probably should, but let's stick to defining the boolean case first :D |
In that case, it seems good. For the record, I did a non-exhaustive search around the Internet for any standard that defined how the values of environment variables should be interpreted as boolean values and could not find anything. 🤷 |
Created the PR including the feedback on this issue. Thanks for everyone's feedback. |
Some environment variables need the definition of a Boolean type.
Example: OTEL_SDK_DISABLED
This discussion started in this PR: #2679
Because this is an important enough subject, we decided to spinoff the definition into this new issue.
The original discussion was proposing the following definition:
Boolean value
Any value that represents a boolean MUST interpret the case-insensitive string
"true"
, meaning"True"
or"TRUE"
are also accepted as"true"
.An SDK MAY extend this definition and define additional values that are interpreted as true.
Any value not explicitly defined here or by the SDK as a true value, including unset and empty values, MUST be interpreted as false.
Also, a recommendation on the naming of environment variable attributes should also be agreed in order to align boolean property names.
The text was updated successfully, but these errors were encountered: