Repository navigation
Provide an option to opt-in Beta (unstable) library #4534
Description
Activity
Generally, I'd prefer to still have some mechanism to enable all unstable instrumentation libraries. My preference would be to add both an
OTEL_PYTHON_MINIMUM_STABILITY_LEVELand anOTEL_PYTHON_UNSTABLE_INSTRUMENTATIONSenvironment variable to handle the common cases of enabling all unstable instrumentation and opting in to a few unstable instrumentations.Even currently, I don't see the addition of these environment variables providing too much benefit to users because you can always just opt to not install the unstable instrumentation packages to begin with. The only scenarios I see where you'd need to rely on
OTEL_PYTHON_MINIMUM_STABILITY_LEVELis if additional packages are being injecting into your Python environment without your control (e.g. AWS Lambda layers)A related change that should be made is to update the
opentelemetry-contrib-instrumentationsto only include stable packages by default, and potentially add a "beta" or "unable" extra that allows users to install all beta packages.Reacted by Jeff LuoHi @herin049 thank you for your feedback.
For
OTEL_PYTHON_UNSTABLE_INSTRUMENTATIONS, do you mean to have it to be a list of enabled instrumentation library or a boolean?FWIW, I think you mean a list of instrumentation libraries so users could:
- Set
OTEL_PYTHON_MINIMUM_STABILITY_LEVELto enable beta. - Set
OTEL_PYTHON_UNSTABLE_INSTRUMENTATIONSto enable some alpha.
Do I understand it correctly?
Reacted by Lukas Hering- Set
Hi @herin049 thank you for your feedback.
For
OTEL_PYTHON_UNSTABLE_INSTRUMENTATIONS, do you mean to have it to be a list of enabled instrumentation library or a boolean?FWIW, I think you mean a list of instrumentation libraries so users could:
- Set
OTEL_PYTHON_MINIMUM_STABILITY_LEVELto enable beta. - Set
OTEL_PYTHON_UNSTABLE_INSTRUMENTATIONSto enable some alpha.
Do I understand it correctly?
Yes, that was my intention. Currently, everything is either beta or stable, so it might not make sense to have a
OTEL_PYTHON_MINIMUM_STABILITY_LEVELat all, and just have aOTEL_PYTHON_UNSTABLE_INSTRUMENTATIONSenvironment variable that also accepts*to enable everything.I'm curious what other people think/prefer.
Reacted by Jeff Luo- Set
IMO, I think we should still add
OTEL_PYTHON_MINIMUM_STABILITY_LEVELdespite everything is either beta or stable in the repo. The OTEP https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/0232-maturity-of-otel.md#maturity-levels lists multipleMaturity levelsand python-contrib should follow it.The proposal you mention is going to be reworked and so I would wait to introduce any new configuration option before that is approved and merged. In the meantime I think the best use of our time could be to continue the work on adding support for stable semantic conventions in the current instrumentations so at least we have something we can call stable.
Reacted by Jeff Luo and Lukas HeringHi @xrmx do you mean it's going to be reworked after open-telemetry/opentelemetry-specification#4813 is merged?
Hi @xrmx do you mean it's going to be reworked after open-telemetry/opentelemetry-specification#4813 is merged?
I mean that the OTEP is being reworked
What problem do you want to solve?
Context
Following the OpenTelemetry Stable by Default proposal, distributions are expected to only enable stable components by default. This prevents users from unknowingly relying on experimental features that might break or change behavior unexpectedly.
In OpenTelemetry Python, we currently have
OTEL_PYTHON_DISABLED_INSTRUMENTATIONSto opt-out of specific instrumentations. However, we lack a clear, standard way to opt-in to unstable (beta/alpha) instrumentations once the "stable by default" policy is enforced.Describe the solution you'd like
Proposed solution
This feature request proposes to introduce a new environment variable and declarative configuration option to allow users to selectively enable unstable instrumentations.
1. Fine-Grained Opt-In
Introduce
OTEL_PYTHON_ENABLED_UNSTABLE_INSTRUMENTATIONS.Type: Comma-separated list of strings (similar to
OTEL_PYTHON_DISABLED_INSTRUMENTATIONS).Behavior: Only the specified unstable instrumentations will be loaded in addition to all stable ones.
Example: OTEL_PYTHON_ENABLED_UNSTABLE_INSTRUMENTATIONS="requests,django"
2. Interaction with Disable List
If an instrumentation is present in both
OTEL_PYTHON_ENABLED_UNSTABLE_INSTRUMENTATIONSandOTEL_PYTHON_DISABLED_INSTRUMENTATIONS, the disable list should take precedence. This ensures that users can easily disable a library even if it was enabled as unstable.Describe alternatives you've considered
Alternative options
A. Coarse-Grained Opt-In (Boolean Flag)
Set the value of
OTEL_PYTHON_ENABLED_UNSTABLE_INSTRUMENTATIONS(or a similar variable) to true/false.Pros: Simple for users who want to test all available unstable instrumentations.
Cons: Violates the principle of least surprise and doesn't allow fine-grained control. If one unstable library is causing issues, the user has to disable all unstable libraries or use the disable list (which might get messy).
B. Minimum Stability Level Threshold
Instead of listing libraries, allow users to set a minimum stability level to load.
Variable:
OTEL_PYTHON_MINIMUM_STABILITY_LEVELValues: stable (default), beta, alpha.
Behavior: If set to beta, both stable and beta libraries are loaded.
Note: This aligns with the suggestion in the stability proposal blog post to "select a desired minimum stability level".
Additional Context
Please let me know which option you prefer.
cc: @aabmass
Would you like to implement a fix?
None
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding
+1orme too, to help us triage it. Learn more here.