Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Real-time Flag Updates Beyond Kubernetes #249

Closed
3 tasks done
beeme1mr opened this issue Jan 9, 2023 · 14 comments · Fixed by #297
Closed
3 tasks done

Real-time Flag Updates Beyond Kubernetes #249

beeme1mr opened this issue Jan 9, 2023 · 14 comments · Fixed by #297
Assignees
@Kavindu-Dodan

Comments

@beeme1mr
Copy link
Member

beeme1mr commented Jan 9, 2023 •
edited

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

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

Next steps
@beeme1mr
Copy link
Member Author

beeme1mr commented Jan 9, 2023

This solution may resolve open-feature/open-feature-operator#250

@AlexsJones
Copy link
Member

Perhaps this should be an OFEP?

@beeme1mr
Copy link
Member Author

@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
Copy link
Contributor

Kavindu-Dodan commented Jan 13, 2023 •
edited

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

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

@Kavindu-Dodan
Copy link
Contributor

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

This was referenced Jan 23, 2023
Merged
Merged
Merged
@Kavindu-Dodan
Copy link
Contributor

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

[1] - open-feature/ofep#45
[2] - #297

beeme1mr pushed a commit that referenced this issue Jan 30, 2023
@Kavindu-Dodan
refactor: introduce add, update and delete operations to sync provide…
0c9a6c3 
…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>
@ekkinox
Copy link

ekkinox commented Feb 2, 2023 •
edited

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
Copy link
Contributor

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)

@toddbaert toddbaert mentioned this issue Feb 6, 2023
Merged
@toddbaert
Copy link
Member

This is related to this OFO issue.

beeme1mr pushed a commit that referenced this issue Feb 7, 2023
@toddbaert
chore: add @Kavindu-Dodan to CODEOWNERS (#377)
e02c899 
@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>
@beeme1mr
Copy link
Member Author

beeme1mr commented Feb 8, 2023

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

@Kavindu-Dodan Kavindu-Dodan mentioned this issue Feb 9, 2023
Closed
@ekkinox
Copy link

ekkinox commented Feb 11, 2023 •
edited

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
Copy link

ekkinox commented Feb 11, 2023

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
Copy link
Member Author

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?

@Kavindu-Dodan Kavindu-Dodan mentioned this issue Feb 14, 2023
Closed
3 tasks
Kavindu-Dodan added a commit that referenced this issue Feb 15, 2023
@Kavindu-Dodan @james-milligan @skyerus
feat: introduce grpc sync for flagd (#297)
33413f2 
## 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>
@beeme1mr beeme1mr reopened this Feb 23, 2023
@beeme1mr