Need to decide what to do w/ the Configuration API

[codeboten]

Currently the api package includes the Configuration api, which isn't part of the spec. This should be moved out before 1.0

[ocelotl]

The Configuration API is a feature that currently resides in the API. It is used by the API, SDK and auto instrumentation plugins.

As mentioned in this issue, it is a problem having the Configuration API in the API because the spec does not include it. Keeping it would put OpenTelemetry Python in a position where this API would have to be kept backwards compatible.

During the SIG, a few solutions were proposed:

1. Move the Configuration API to the SDK. This would have the disadvantage of making the auto instrumentation plugins depend on the SDK which is something to be avoided. This would also mean that the API would have to have its own "manual" environment variable configuration manager.
2. Move the Configuration API to its own separate package. This has the problem that the auto instrumentation plugins would have a hard dependency on this specific configuration manager, which can be problematic or at least redundant if there is already another configuration manager present in the user virtual environment.
3. Move the Configuration API to the opentelemetry-instrumentation package. This would mean that the API and the SDK would have to have their own "manual" environment variable configuration manager.

It is also important to notice that something that concerns us is the fact that we will probably want to increase the features of this configuration manager, for example, adding support for configuration stored in configuration files and configuration passed via command line arguments.

It was mentioned that the most "by-the-book-correct" approach would be to remove the configuration manager completely from this repo, and considering that other languages also need to handle configuration via environment variables, we should open up an OTEP or an issue in the spec repo and go through all the process of adding a section to the specification that defines how configuration managers should work. Nevertheless, this is not necessarily the most practical or convenient process if we take into consideration time, effort, etc.

Now, there is an important design concern here. The functionality in the configuration API has nothing to do with spans, metrics, or anything else OpenTelemetry-related. In fact, if the configuration API was moved into its own opentelemetry-configuration package, it could be used by any project that needed configuration management. For this reason, I think that it would not be accepted into the specification.

As mentioned in the SIG, this API is actually just a more convenient feature that is not strictly necessary. Our next plans for this API are to add support for configuration files, and to make the environment variables override any conflicts that may happen between a configuration file and them. If we carry on with this approach, we would end up just adding a feature that at least another configuration manager provides already.

I understand that using a third-party library as a dependency in this project can cause some uneasiness, but:

1. We already do it with wrapt
2. Again, configuration management is as unrelated to OpenTelemetry as wrapt is.

I find it hard to justify more effort being put in reimplementing functionality that is already present in a third party module. Having our own configuration manager gives us more control but it may not be worth the cost.

TL;DR

I say we remove the configuration API completely and replace it by a third party package.

[lzchen]

2. Move the Configuration API to its own separate package.

We also don't want (eventually) GA packages (like API and SDK) to depend on a package that could potentially have breaking changes.

Another solution is to have the Configuration API only as a "helper" api used internally. We will try our best to not expose it in any user-facing documentation related to tracing/metrics/logs. Instrumentation library authors MAY use it to their own discretion but we do not have a guarantee that there will not be any breaking changes. This way, we can have potentially breaking changes to the Configuration API without violating the promise that Opentelemetry has to customers (keep it separate from the other OT components, it is just a "feature" or "add-on"). With this method, we will most likely move the Configuration API into it's own package. Either opentelemetry-configuration or we can have a generic add-on package that could potentially contain other useful (but not speced out) functionality.

I say we remove the configuration API completely and replace it by a third party package.

I am okay with this too except for depending on a third-party package. Can we not just access environment variables manually and not rely on an api? It might be more code but it shouldn't be that difficult?

[ocelotl]

As discussed in the SIG, the best we can do now is to remove Configuration entirely for the release. Later we can decide what to do.

[owais]

Post 1.0, having it back as an "internal" module would really be great. I think it was very nice to have and could have added more convenience and safety to dealing with config values.

[lzchen]

@owais
If that is the case why leave it till after 1.0.0?