Multi Provider for OpenFeature

[beeme1mr]

Overview

A multi provider acts as a unified abstraction layer, allowing developers to consolidate feature flag access through a single API. With a multi provider, developers can simultaneously support multiple providers, making it easier to migrate between them.

Requirements

Tasks

Preview Give feedback

1. Define a name for the provider
2. Document supported scenarios
3. Create a sequence diagram describing the data flow of each scenario
4. Implement the provider in multiple languages
5. Document the requirements in the OpenFeature spec

Resources

• https://cloud-native.slack.com/archives/C0344AANLA1/p1713969371600029
• Kickoff meeting:
  • https://dynatrace.zoom.us/rec/share/2_BnAhWfih9DOiDG6WHwDC3zY49oe5EpX6a_tJ1fxzS7cexsEEts4VH8BG_Scyhl.I_01yQKFixmdPEdg
  • password: N0EPq=Q6

Ideas

• Flag metadata could be used to understand what provider was used to resolve the flag value
• Debug logging could be offloaded to an optional hook
• Extend appendix-a to include a section on the meta provider
• Leverage the evaluation details returned by the provider.

Pseudo code

OpenFeature.setProvider(
  new MetaProvider([
    new EnvVarProvider(),
    new DbProvider(),
    new NextGenProvider3000(),
  ])
)

Questions

• Should the meta provider live in the SDK or the contribs repo?
• Can the meta provider support provider hooks?
• What strategies should be supported out of the box?
• How should we handle provider events?

Prior art

• feat: vendor migration provider js-sdk-contrib#613
• feat: Add MetaProvider gem and basic implementation ruby-sdk-contrib#17

[federicobond]

One key detail that came up when I did a PoC of an aggregated provider like this is how to handle provider events (and lifecycle) outside of the main provider registry (using SDK-specific, not spec terminology here).

Providers can emit events spontaneously and these events will have to be routed through the meta provider before bubbling to the main SDK event handling code, as they would belong to an unregistered provider.

It's hard to avoid this because events are necessary to properly keep track of each provider status. SDKs might want to provide a standard implementation of such a provider lifecycle manager to ease the writing of aggregated providers and ensure consistency in handling events and status changes.

[weyert]

I like the idea of this provider but I am not super excited about the name of it. It's pretty meta (🤭)

For OpenTelemetry I have a similar thing for the exporters so it sends it both to otel-collector and Stackdriver and I could this the CompositeExporter.

Maybe some naming similar to that might be more clarifying?

[maxveldink]

Meta was a better name than multiple_source from my original implementation 😂 But, I do like the idea of composite and am open to other name ideas too.

The only strategy currently implemented in the Ruby contrib is first_match, which short-circuits when we get a successful resolution details match from a provider. The other one I'm immediately thinking about is one that evaluates all providers (so logging hooks can be executed) for a flag and allows specifying a precedence order. Those are the two most important use cases I can foresee.

[markphelps]

👋🏻 just throwing my two cents re: naming. I also like CompositeProvider

Another idea: MultiProvider like io.MultiReader in Go

[federicobond]

I think we need to dig into the specific scenarios or use cases before we decide on naming because we can very well be talking about different provider implementations altogether.

For example, a CompareProvider (a provider that registers differences between the evaluation results of two different providers may be orthogonal to (and composable with) a StackProvider (a provider that returns the first match from a stack of providers.

[lukas-reining]

I think we need to dig into the specific scenarios or use cases before we decide on naming because we can very well be talking about different provider implementations altogether.

I am with you @federicobond. Having this would maybe make it more clear and also delimit it from other not "in-scope" use cases.