Adopt SDK Configuration Pattern using Environment Variables

[askpt]

Overview

This issue proposes that the OpenFeature Protocol project consider adopting a configuration pattern for its SDKs similar to the approach outlined by OpenTelemetry (OTEL): https://opentelemetry.io/docs/concepts/sdk-configuration/

Context

Allowing the consumers to specify the OFREP configuration as an environment variables, would make the configuration more flexible. By using a well defined variable names defined by the SIG, we can enforce the consumers to know which variables can be used.

Discussion Points

• How could this configuration principles be applied to OpenFeature Protocol?
• Are there any compatibility or migration concerns?
• What would a roadmap or next steps look like for exploration and possible adoption?
• Which environment variables should be defined?

Proposed variables

• OFREP_ENDPOINT -> http://localhost:2321
• OFREP_HEADERS -> "Authentication=Bearer 123,Content-Type=json"
• OFREP_TIMEOUT -> 5000

[erka]

Should we maybe generalize it and use OF_ENDPOINT instead? I think the configuration is pretty similar across all OF providers, including ofrep,flagd, goff, etc...

[slashmo]

I like how the OTel spec groups everything into OTel at the first level and then nests the OTLP specific configuration inside. Have you considered this approach for OFREP as well so we leave room for a common root key that's used by OFREP but also any other potential top-level OpenFeature configuration?

Following the example of OTEL_EXPORTER_OTLP_ENDPOINT, we could have OPEN_FEATURE_PROVIDER_OFREP_ENDPOINT, OPENFEATURE_PROVIDER_OFREP_ENDPOINT, OF_PROVIDER_OFREP_ENDPOINT, OPEN_FEATURE_OFREP_ENDPOINT, OPENFEATURE_OFREP_ENDPOINT or OF_OFREP_ENDPOINT?

[askpt]

@erka I believe if we want to target other OF native providers (flagd, goff, etc...) we should write it as "recommendation" rather than enforcing it. This issue is only targeting OFREP, to recommend to other providers, we would need to do it at spec level?

@slashmo, that is a great suggestion. Could you please add it in the ADR so we can have a better place to discuss the variable implementation? I only added here as a suggestion, where the ADR will be the required implementation. See it here: #54

[erka]

@askpt I’m talking about the environment variable names only right now. In the future, there might be a move to standardize OF_... variables at the spec level, and OFREP would then need to support both or introduce breaking changes.

Let's say I have a product with OFREP integration and flagd as the feature flag provider. At some point, I might want to experiment with flagd. It has OFREP, remote and in-process providers. If it's implemented the same way across OF ecosystem, I could simply switch OF_PROVIDER environment variable between flagd, ofrep or flagd-in-process and play with it. No code changes required.

[askpt]

@askpt I’m talking about the environment variable names only right now. In the future, there might be a move to standardize OF_... variables at the spec level, and OFREP would then need to support both or introduce breaking changes.

Let's say I have a product with OFREP integration and flagd as the feature flag provider. At some point, I might want to experiment with flagd. It has OFREP, remote and in-process providers. If it's implemented the same way across OF ecosystem, I could simply switch OF_PROVIDER environment variable between flagd, ofrep or flagd-in-process and play with it. No code changes required.

@erka Sorry if I misunderstood. So you saying something like @slashmo suggested here: #54 (comment)

[erka]

@erka Sorry if I misunderstood. So you saying something like @slashmo suggested here: #54 (comment)

@askpt No, I prefer the OF_ENDPOINT or OPENFEATURE_ENDPOINT environment variable, as it can act as a common configuration point for different providers.

Personally, I don’t really see a difference between OFREP_ENDPOINT and OPENFEATURE_PROVIDER_OFREP_ENDPOINT. It would only be used by OFREP provider.

[askpt]

@jonathannorris It seems the MCP is using some environment variables. I opened this issue to standardise them and make it available in the SDKs.

[erka]

Could we use "300ms", "1s" or "5m" for OFREP_TIMEOUT?

[askpt]

Could we use "300ms", "1s" or "5m" for OFREP_TIMEOUT?

I think it is easier to use an integer as milliseconds. The reason is it reduces the complexity for parsing, since we just need to care about positive numbers instead of positive numbers and unit.

[erka]

@askpt is there any update on this one?

[askpt]

@askpt is there any update on this one?

@erka, I am still waiting for feedback on ADR #54