[TC Request]: Environment-based Configuration Guidance

[Aneurysm9]

For a long time there has been a recognition that using environment variables as a configuration mechanism has limitations and that we will require a formalized configuration mechanism for OpenTelemetry SDK implementations. Though there appears to be broad support for the concept of a configuration file, it has not been a priority in part because we have thus far always made the choice to simply add more environment variables for configuration. With #2857 we have encountered a configuration point that is beyond the abilities of our current environment variable-based configuration system. In discussion during the Spec SIG meeting on 2022-10-18 there was support for declaring a moratorium on the definition of new environment variables for configuration purposes until an alternate configuration mechanism that can support the full range of configuration options is available and agreement that such a declaration should come from the Technical Committee.

This issue serves to track the request that the Technical Committee communicate its consensus position regarding whether the specification should cease adding or extending environment variable-based configuration until such time as a fully-functional alternate configuration mechanism is defined in stable specification with multiple inter-operating implementations available.

[carlosalberto]

This has been accepted as an important item to pay attention to, and the TC started discussing this, and will follow up as expected.

[jsuereth]

The TC has decided to put a moratorium on environment variable configuration related changes until a formalized configuration mechanism is in place.

The current SDK environment variable configuration will not be extended with anything following:

• Anything that is not statically typed. That is every environment variable must have a known expected type.
• Anything that has a non-primitive type (see here for the list of primitive types)
• No new complex type encodings in environment variables (arrays, maps, etc).
  • No Repeatable values (e.g. env variables, with an index in a name, like OTEL_FOO_1, OTEL_FOO_2)
  • No variable environmental name patterns, e.g. OTEL_FOO_{some set of allowed values}

Additionally, new environment variable use-cases will be evaluated and non-essential use-cases may still be blocked on a full configuration specification.

Further restrictions will be added here as needed.

[joaopgrassi]

formalized configuration mechanism is in place.

Just to be clear, now this "formalized mechanism" will be the file based configuration?

[svrnm]

@open-telemetry/technical-committee this issue seems to be a tracker for the moratorium on environment variables, we wonder if this should be pinned (and renamed to highlighting this moratorium) such that it is easier to be found. This issue will be closed when the configuration is put in place and it is no longer needed to have a moratorium.

[jack-berg]

Discussed in the 5/15/24 TC meeting.

The TC opinion is that the moratorium exists in the form of this issue comment. The moratorium was put in place to create space for file configuration, which has made progress and has momentum - please refer to the file configuration project borad for tracking the status. Closing this issue, but closing does not indicate a change or removal in the moratorium. If folks wish to codify anything in particular about the moratorium in the spec, please open another issue to describe that proposal.