-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Real-time Flag Updates Beyond Kubernetes #249
Comments
This solution may resolve open-feature/open-feature-operator#250 |
Perhaps this should be an OFEP? |
@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. |
I will start a POC with gRPC and see how this fits to flagd. Throught POC I will see,
|
General refactoring of flag update providers (isync impls) - #291 |
OFEP is ready [1] along with POC [2] [1] - open-feature/ofep#45 |
…rs (#307) ## This PR Introduce and wire new strategies to sync provider state updates. Following new mechanisms were added to be used by sync providers (ex:- file based flag configuration provider), - ADD: Add new flag(s) to internal state - UPDATE: Update existing flag(s) to internal state - DELETE: Remove flag(s) from internal state These operations provide extra flexibility compared to the existing "merge" operation, which is now mapped to "ALL" (i.e - Add and replace all). Test coverage of 100% for newly added methods. ### Related Issues Related to #249 --------- Signed-off-by: Kavindu Dodanduwa <kavindudodanduwa@gmail.com>
I'm really eager to be able to test this. |
OFEP is approved (open-feature/ofep#45) & POC is working (#297) I will open the first PR once schema changes are approved and grpc dependencies are deployed to buf (open-feature/flagd-schemas#78) |
This is related to this OFO issue. |
@Kavindu-Dodan has contributed multiple significant changes and proposals to flagd: - multiple refactors: #291, #307 - ci/security improvements: #338, #337 - architectural proposals (some of which got some attention from outside parties!): open-feature/ofep#45, open-feature/flagd-schemas#78, #249 (comment) - load testing: #225 - documentation improvements For these reasons, I believe he should be made a CODEOWNER in this repository. NOTE: before this is merged, @Kavindu-Dodan should be added with at least `maintainer` permissions to the repo. Signed-off-by: Todd Baert <toddbaert@gmail.com>
Hey @ekkinox, @Kavindu-Dodan's PR is for review. If you have a moment, you feedback on the PR would be appreciated. |
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 ! |
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 ? |
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? |
## This PR Attempts to resolve #249 by introducing grpc sync provider to flagd. OFEP [approved] - https://github.com/open-feature/ofep/blob/main/OFEP-flagd-grpc-sync.md ### How to test/run ? Flagd acts as the grpc client, hence you need at least a minimal mock server. For this, you can utilize this [1] server implementation. Startup arguments of flagd now support grpc target uri. This can be provided with `grpc://` , for example, `./flagd start --uri grpc://localhost:8090` ### Technical highlights - GRPC protobuf definitions are available in buf [2] and are backed by the schema repository (https://github.com/open-feature/schemas) - Initial connection must be successful (i.e- grpc server/target must be accepting connections) - Subsequent server connection losses will not result in a runtime failure and connection re-establishment attempts will be performed ### What is not included (follow up improvements) - Connection security: This version does not enforce connection security. This will be addressed with follow-up improvements (ex:- TLS enabled connections). Hence, strongly recommends not using this version in production scenarios (fixed by #398) - Server implementations: This sync provider was designed to be open and connects to any server implementation. Hence there is no default server implementation. You may create your own server implementation based on grpc schemas. [1] - https://github.com/Kavindu-Dodan/flagd-grpc-sync-server [2] - https://buf.build/open-feature/flagd --------- Signed-off-by: Kavindu Dodanduwa <kavindudodanduwa@gmail.com> Signed-off-by: Kavindu Dodanduwa <Kavindu-Dodan@users.noreply.github.com> Co-authored-by: James Milligan <75740990+james-milligan@users.noreply.github.com> Co-authored-by: Skye Gill <gill.skye95@gmail.com>
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. |
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
Next steps
The text was updated successfully, but these errors were encountered: