From 5b9f9dd5dc188a62e5b9607bedd598df4765fd42 Mon Sep 17 00:00:00 2001 From: Skye Gill Date: Mon, 20 Mar 2023 16:41:04 +0000 Subject: [PATCH 1/7] feat: add proposal for ofo flagd service Signed-off-by: Skye Gill --- OFEP-ofo-flagd-service.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 OFEP-ofo-flagd-service.md diff --git a/OFEP-ofo-flagd-service.md b/OFEP-ofo-flagd-service.md new file mode 100644 index 0000000..7bd914e --- /dev/null +++ b/OFEP-ofo-flagd-service.md @@ -0,0 +1,14 @@ +## flagd service deployment driven by OpenFeature Operator + +## State: DRAFTING + +Currently, OpenFeature Operator (OFO) manages the deployment of 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 the deployment of externally accessible flagd (e.g. from client side applications, or even server side applications that don't want to use the sidecar pattern). + +## Background + +The driving force behind this is to simplify the deployment of flagd 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 FlagdService custom resource definition (CRD) and controller. +The controller uses the configuration defined within the custom resource (CR) to create a Service and a Deployment of flagd (backed by the Service). This is a common deployment pattern permitting access by any component that routes to the created Service (e.g. Ingress/Load Balancer). From 4592717e24c266bceb6e75c1d8c21aa2c3e1c21c Mon Sep 17 00:00:00 2001 From: Skye Gill Date: Mon, 20 Mar 2023 16:44:07 +0000 Subject: [PATCH 2/7] spacing Signed-off-by: Skye Gill --- OFEP-ofo-flagd-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OFEP-ofo-flagd-service.md b/OFEP-ofo-flagd-service.md index 7bd914e..21b6be4 100644 --- a/OFEP-ofo-flagd-service.md +++ b/OFEP-ofo-flagd-service.md @@ -2,7 +2,7 @@ ## State: DRAFTING -Currently, OpenFeature Operator (OFO) manages the deployment of 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 the deployment of externally accessible flagd (e.g. from client side applications, or even server side applications that don't want to use the sidecar pattern). +Currently, OpenFeature Operator (OFO) manages the deployment of 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 the deployment of externally accessible flagd (e.g. from client side applications, or even server side applications that don't want to use the sidecar pattern). ## Background From 87b0f1eac5463be760f30b50f25cd33ff0b17d38 Mon Sep 17 00:00:00 2001 From: Skye Gill Date: Tue, 21 Mar 2023 10:31:42 +0000 Subject: [PATCH 3/7] review suggestions Signed-off-by: Skye Gill --- OFEP-ofo-flagd-service.md | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/OFEP-ofo-flagd-service.md b/OFEP-ofo-flagd-service.md index 21b6be4..fee5c8f 100644 --- a/OFEP-ofo-flagd-service.md +++ b/OFEP-ofo-flagd-service.md @@ -11,4 +11,23 @@ The driving force behind this is to simplify the deployment of flagd for use by ## Proposal Introduce a FlagdService custom resource definition (CRD) and controller. -The controller uses the configuration defined within the custom resource (CR) to create a Service and a Deployment of flagd (backed by the Service). This is a common deployment pattern permitting access by any component that routes to the created Service (e.g. Ingress/Load Balancer). +The controller uses the configuration defined within the custom resource (CR) to create a Service and a Deployment of flagd (backed by the Service) in the configured namespace. 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 internally routable flagd. In contrast, the described FlagdService pattern permits externally routable flagd. + +### RBAC + +OFO already has RBAC to Deployments but not Services so the following is required. + +``` +- apiGroups: + - "" + resources: + - services + verbs: + - create + - delete + - get + - list + - patch + - update + - watch +``` From 4575e56ab0a06a92ff9ca5ea0af0aaa5fc110e78 Mon Sep 17 00:00:00 2001 From: Skye Gill Date: Tue, 21 Mar 2023 10:51:31 +0000 Subject: [PATCH 4/7] namespace clarification Signed-off-by: Skye Gill --- OFEP-ofo-flagd-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OFEP-ofo-flagd-service.md b/OFEP-ofo-flagd-service.md index fee5c8f..21e3ed1 100644 --- a/OFEP-ofo-flagd-service.md +++ b/OFEP-ofo-flagd-service.md @@ -11,7 +11,7 @@ The driving force behind this is to simplify the deployment of flagd for use by ## Proposal Introduce a FlagdService custom resource definition (CRD) and controller. -The controller uses the configuration defined within the custom resource (CR) to create a Service and a Deployment of flagd (backed by the Service) in the configured namespace. 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 internally routable flagd. In contrast, the described FlagdService pattern permits externally routable flagd. +The controller uses the configuration defined within the custom resource (CR) to create a Service and a Deployment of flagd (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 internally routable flagd. In contrast, the described FlagdService pattern permits externally routable flagd. ### RBAC From 8118d376e2a897f9a895871af3b96338acbb6219 Mon Sep 17 00:00:00 2001 From: Skye Gill Date: Tue, 21 Mar 2023 13:00:35 +0000 Subject: [PATCH 5/7] generalise to flag providers Signed-off-by: Skye Gill --- OFEP-ofo-flag-service.md | 33 ++++++++++++++++++++++++++++++++ OFEP-ofo-flagd-client-support.md | 2 +- OFEP-ofo-flagd-service.md | 33 -------------------------------- 3 files changed, 34 insertions(+), 34 deletions(-) create mode 100644 OFEP-ofo-flag-service.md delete mode 100644 OFEP-ofo-flagd-service.md diff --git a/OFEP-ofo-flag-service.md b/OFEP-ofo-flag-service.md new file mode 100644 index 0000000..19ef238 --- /dev/null +++ b/OFEP-ofo-flag-service.md @@ -0,0 +1,33 @@ +## 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 the deployment of an externally accessible flag provider (e.g. from client side applications, or even server side applications that don't want to use the sidecar pattern). + +## 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 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 the following is required. + +``` +- apiGroups: + - "" + resources: + - services + verbs: + - create + - delete + - get + - list + - patch + - update + - watch +``` 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 diff --git a/OFEP-ofo-flagd-service.md b/OFEP-ofo-flagd-service.md deleted file mode 100644 index 21e3ed1..0000000 --- a/OFEP-ofo-flagd-service.md +++ /dev/null @@ -1,33 +0,0 @@ -## flagd service deployment driven by OpenFeature Operator - -## State: DRAFTING - -Currently, OpenFeature Operator (OFO) manages the deployment of 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 the deployment of externally accessible flagd (e.g. from client side applications, or even server side applications that don't want to use the sidecar pattern). - -## Background - -The driving force behind this is to simplify the deployment of flagd 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 FlagdService custom resource definition (CRD) and controller. -The controller uses the configuration defined within the custom resource (CR) to create a Service and a Deployment of flagd (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 internally routable flagd. In contrast, the described FlagdService pattern permits externally routable flagd. - -### RBAC - -OFO already has RBAC to Deployments but not Services so the following is required. - -``` -- apiGroups: - - "" - resources: - - services - verbs: - - create - - delete - - get - - list - - patch - - update - - watch -``` From fc02e22498b5174fa43edd6beae111d67bb4a3c7 Mon Sep 17 00:00:00 2001 From: Skye Gill Date: Tue, 21 Mar 2023 15:35:56 +0000 Subject: [PATCH 6/7] constrict services scope Signed-off-by: Skye Gill --- OFEP-ofo-flag-service.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/OFEP-ofo-flag-service.md b/OFEP-ofo-flag-service.md index 19ef238..dfe8305 100644 --- a/OFEP-ofo-flag-service.md +++ b/OFEP-ofo-flag-service.md @@ -11,13 +11,20 @@ The driving force behind this is to simplify the deployment of flag providers fo ## 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 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. +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 the following is required. +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: @@ -31,3 +38,5 @@ OFO already has RBAC to Deployments but not Services so the following is require - update - watch ``` + +This restricts OFO's Service mutation scope to within its namespace. From 9afcf622cf4adf36519f9528573aec4cb202eaa6 Mon Sep 17 00:00:00 2001 From: Skye Gill Date: Thu, 23 Mar 2023 09:41:21 +0000 Subject: [PATCH 7/7] clarification Signed-off-by: Skye Gill --- OFEP-ofo-flag-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OFEP-ofo-flag-service.md b/OFEP-ofo-flag-service.md index dfe8305..6c7f947 100644 --- a/OFEP-ofo-flag-service.md +++ b/OFEP-ofo-flag-service.md @@ -2,7 +2,7 @@ ## 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 the deployment of an externally accessible flag provider (e.g. from client side applications, or even server side applications that don't want to use the sidecar pattern). +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