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.

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

feat: add proposal for ofo flagd service #59

Merged
merged 7 commits into from
Mar 23, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions OFEP-ofo-flag-service.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
## flag service deployment driven by OpenFeature Operator

## State: DRAFTING

Currently, OpenFeature Operator (OFO) manages the deployment of a flag provider (e.g. flagd) by appending it to a pod's containers (sidecar pattern), thereby allowing containers within the pod to route to it. This OFEP campaigns for the extension of OFO to manage flag providers by abstracting a Kubernetes Deployment resource.

## Background

The driving force behind this is to simplify the deployment of flag providers for use by client side applications. An [OFEP was drafted](./OFEP-ofo-flagd-client-support.md) to achieve this but subsequently withdrawn (reasons noted within). This OFEP recognises the limitations of the previous, presenting a modular solution with a broader scope.

## Proposal

Introduce a FlagService custom resource definition (CRD) and controller.
The controller uses the configuration defined within the custom resource (CR) to create a Service (in OFO's namespace) and a Deployment of a flag provider (backed by the Service) in the same namespace as the CR. This is a common deployment pattern permitting access by any component that routes to the created Service (e.g. Ingress/Load Balancer). OFO already manages the [sidecar deployment pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar) to achieve the goal of an internally routable flag provider. In contrast, the described FlagService pattern permits an externally routable flag provider.

### RBAC

OFO already has RBAC to Deployments but not Services so (at minimum) the following is required.

```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: manager-role
namespace: open-feature-operator-system
rules:
- apiGroups:
- ""
resources:
- services
verbs:
- create
- delete
- get
- list
- patch
- update
- watch
```

This restricts OFO's Service mutation scope to within its namespace.
2 changes: 1 addition & 1 deletion OFEP-ofo-flagd-client-support.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ _Withdrawn for the following reasons:_
- _OFO would require CRUD permissions for HTTPRoutes & Gateways, introducing security concerns._
- _Kubernetes Gateway API is still in beta._

_[OFEP for an alternative solution](./OFEP-ofo-flagd-service.md)._
_[OFEP for an alternative solution](./OFEP-ofo-flag-service.md)._

## Background

Expand Down