Real-time Flag Updates Beyond Kubernetes

[beeme1mr]

Problem

Flagd supports various sync options include watching a local file, HTTP polling, and subscribing to the Kubernetes API. In most configurations, the Kubernetes API is the only option that currently supports near real-time flag configuration updates. This introduces some challenges in Kubernetes clusters that do not allow direct access to the API and environments that are not using Kubernetes at all. A more flexible sync option that supports real-time flag updates would help overcome these challenges.

Requirements

• [x] Flag changes are reflected in near real-time in flagd
• [x] The new real-time flagd sync does not rely on the Kubernetes API
• [x] More robust testing of TLS support in CI

Next steps

• Real-time Flag Update via gRPC in Kubernetes

[beeme1mr]

This solution may resolve https://github.com/open-feature/open-feature-operator/issues/250

[AlexsJones]

Perhaps this should be an OFEP?

[beeme1mr]

@AlexsJones sure, we can start there. This was meant to be more of an epic level problem statement. Unfortunately, GitHub requires all issues to be associated with a repo even if they're higher level.

My initial thought is that we could add a gRPC sync that would theoretically solve all the problems listed above but I'm open to suggestions. Starting with an OFEP would be a good place to start.

[Kavindu-Dodan]

I will start a POC with gRPC and see how this fits to flagd. Throught POC I will see,

• [x] Refactoring of current sync methods
• [x] gRPC sync method & limitations
• [x] OFEP and Approval
• [x] Basic implementation
• [x] Security considerations & Options

[Kavindu-Dodan]

General refactoring of flag update providers (isync impls) - #291

[Kavindu-Dodan]

OFEP is ready [1] along with POC [2]

[1] - https://github.com/open-feature/ofep/pull/45 [2] - https://github.com/open-feature/flagd/pull/297

[ekkinox]

I'm really eager to be able to test this. Making flagd fed from grpc streams is imo one of the best move that could be done (great flexibility + ~ instant updates)

[Kavindu-Dodan]

OFEP is approved (https://github.com/open-feature/ofep/pull/45) & POC is working (https://github.com/open-feature/flagd/pull/297)

I will open the first PR once schema changes are approved and grpc dependencies are deployed to buf (https://github.com/open-feature/schemas/pull/78)

[toddbaert]

This is related to this OFO issue.

[beeme1mr]

Hey @ekkinox, @Kavindu-Dodan's PR is for review. If you have a moment, you feedback on the PR would be appreciated.

[ekkinox]

I'm really eager to be able to test this. Making flagd fed from grpc streams is imo one of the best move that could be done (great flexibility + ~ instant updates)

Sorry for delay, from what I see it's very promising, approved ! I added a minor comment though.

Also, do you think it could be useful to link in the docs some simple gRPC server app example (go + proto) that feeds flagd via gRPC sync ? It imo would ease devs ramp us on such sync usage.

In any cases, thx for this !

[ekkinox]

Any plans to extend this grpc compatibility to the flagd operator? I mean by this being able to configure flagd sidecars to be fed by a grpc application ?

[beeme1mr]

Hey @ekkinox, that will be the next step. I've updated the issue description to better reflect goal. Does this align with what you were hoping for?

[beeme1mr]

I reduced the scope of this issue so it could be closed. There's a dedicated project board that can track the progress of using gRCP in the OpenFeature Operator.