From c4553a15b12d085946ddce437c4964bc41d553c1 Mon Sep 17 00:00:00 2001
From: Skye Gill <gill.skye95@gmail.com>
Date: Thu, 23 Mar 2023 21:01:56 +0000
Subject: [PATCH] feat: add proposal for ofo flagd service (#59)

Signed-off-by: Skye Gill <gill.skye95@gmail.com>
---
 OFEP-ofo-flag-service.md         | 42 ++++++++++++++++++++++++++++++++
 OFEP-ofo-flagd-client-support.md |  2 +-
 2 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 OFEP-ofo-flag-service.md

diff --git a/OFEP-ofo-flag-service.md b/OFEP-ofo-flag-service.md
new file mode 100644
index 0000000..6c7f947
--- /dev/null
+++ b/OFEP-ofo-flag-service.md
@@ -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.
diff --git a/OFEP-ofo-flagd-client-support.md b/OFEP-ofo-flagd-client-support.md
index beeb498..dfa8aed 100644
--- a/OFEP-ofo-flagd-client-support.md
+++ b/OFEP-ofo-flagd-client-support.md
@@ -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