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:

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.
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.
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:

We already do it with wrapt
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.

Need to decide what to do w/ the Configuration API #1494

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions