From 07bf7cdbf14a55e4f62b194c8283140a40edfce0 Mon Sep 17 00:00:00 2001 From: Phil Brookes Date: Wed, 11 Oct 2023 09:10:33 +0100 Subject: [PATCH 1/7] start policy sync rfc --- .gitignore | 1 + rfcs/0004-policy-sync-v1.md | 98 +++++++++++++++++++++++++++++++++++++ 2 files changed, 99 insertions(+) create mode 100644 .gitignore create mode 100644 rfcs/0004-policy-sync-v1.md diff --git a/.gitignore b/.gitignore new file mode 100644 index 00000000..2464dd91 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +./idea diff --git a/rfcs/0004-policy-sync-v1.md b/rfcs/0004-policy-sync-v1.md new file mode 100644 index 00000000..c22dabca --- /dev/null +++ b/rfcs/0004-policy-sync-v1.md @@ -0,0 +1,98 @@ +# RFC - Policy Sync + +- Feature Name: `policy_sync_v1` +- Start Date: 2023-10-10 +- RFC PR: [Kuadrant/architecture#0000](https://github.com/Kuadrant/architecture/pull/0000) +- Issue tracking: [https://github.com/Kuadrant/architecture/issues/26](https://github.com/Kuadrant/architecture/issues/26) + +# Summary +[summary]: #summary + +Enable policies defined in the control plane (hub) to be synced to the data plane (spoke clusters). + +# Motivation +[motivation]: #motivation + +Currently any policies targeting gateways in the spokes need to be defined in the spokes, and it can be cumbersome, time-consuming and error prone to require these to be duplicated across multiple spoke clusters. + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +Explain the proposal as if it was implemented and you were teaching it to Kuadrant user. That generally means: + +- Introducing new named concepts. +- Explaining the feature largely in terms of examples. +- Explaining how a user should *think* about the feature, and how it would impact the way they already use Kuadrant. It should explain the impact as concretely as possible. +- If applicable, provide sample error messages, deprecation warnings, or migration guidance. +- If applicable, describe the differences between teaching this to existing and new Kuadrant users. + +The policy sync system will allow a gateway-admin to create or modify a gateway class at the hub level and specify a series of GVKs for that gatewayClass (for example the AuthPolicy GVK). + +When a gateway is created in the hub that uses this gatewayClass, any AuthPolicies that target that gateway will be watched by the MGC. + +When these gateways are placed on a spoke, any AuthPolicies targeting that gateway will also be placed on that same spoke. + +When the AuthPolicies are placed on the relevant spokes, they will be manipulated to target the new gateway in the spoke. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +This is the technical portion of the RFC. Explain the design in sufficient detail that: + +- Its interaction with other features is clear. +- It is reasonably clear how the feature would be implemented. +- How error would be reported to the users. +- Corner cases are dissected by example. + +The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. + +# Drawbacks +[drawbacks]: #drawbacks + +Why should we *not* do this? + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +- Why is this design the best in the space of possible designs? +- What other designs have been considered and what is the rationale for not choosing them? +- What is the impact of not doing this? + +#### We will not be using the policy framework to complete this objective: +The policy framework is an improvement on the system currently used to place resources on spoke clusters from the hub, essentially removing the need to read the placement decision and manually create manifestworks. + +As such, we might want to eventually look at migrating to using the system for all hub > spoke placements. + +However, the policy framework currently has a significant limitation preventing our usecase, which is that we cannot read the status back from the resources created in the spoke. + +The current proposal, regarding this work, is to proceed with our current manifestwork solution, and migrate all hub > spoke placement logic if the policy framework reaches a point that it is more feasible. + +# Prior art +[prior-art]: #prior-art + +Discuss prior art, both the good and the bad, in relation to this proposal. +A few examples of what this can include are: + +- Does another project have a similar feature? +- What can be learned from it? What's good? What's less optimal? +- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. + +This section is intended to encourage you as an author to think about the lessons from other tentatives - successful or not, provide readers of your RFC with a fuller picture. + +Note that while precedent set by other projects is some motivation, it does not on its own motivate an RFC. + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +- What parts of the design do you expect to resolve through the RFC process before this gets merged? +- What parts of the design do you expect to resolve through the implementation of this feature before stabilization? +- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? + +# Future possibilities +[future-possibilities]: #future-possibilities + +Think about what the natural extension and evolution of your proposal would be and how it would affect the platform and project as a whole. Try to use this section as a tool to further consider all possible interactions with the project and its components in your proposal. Also consider how this all fits into the roadmap for the project and of the relevant sub-team. + +This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. + +Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information. \ No newline at end of file From ec0d805c36b87dc3e8a445513a6d8530c65b0691 Mon Sep 17 00:00:00 2001 From: Phil Brookes Date: Fri, 13 Oct 2023 11:54:07 +0100 Subject: [PATCH 2/7] very rough first pass of policy sync RFC --- .gitignore | 2 +- rfcs/0004-policy-sync-v1.md | 70 ++++++++++++++++--------------------- 2 files changed, 32 insertions(+), 40 deletions(-) diff --git a/.gitignore b/.gitignore index 2464dd91..485dee64 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1 @@ -./idea +.idea diff --git a/rfcs/0004-policy-sync-v1.md b/rfcs/0004-policy-sync-v1.md index c22dabca..d9df8664 100644 --- a/rfcs/0004-policy-sync-v1.md +++ b/rfcs/0004-policy-sync-v1.md @@ -8,23 +8,21 @@ # Summary [summary]: #summary -Enable policies defined in the control plane (hub) to be synced to the data plane (spoke clusters). +When a gateway in the hub is targeted by a policy in the hub, enable the gateway controller to be able to sync both the gateway and policy together to spoke clusters. # Motivation [motivation]: #motivation -Currently any policies targeting gateways in the spokes need to be defined in the spokes, and it can be cumbersome, time-consuming and error prone to require these to be duplicated across multiple spoke clusters. +Currently, any policies targeting gateways in the spokes need to be defined in the spokes, and it can be cumbersome, time-consuming and error prone to require these to be duplicated across multiple spoke clusters. + +Gateway-admin has a set of homogeneous clusters and needs to apply per cluster rate limits across the entire set. + +Platform-admin with a set of clusters with rate limits applied needs to change rate limit for one particular cluster. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation -Explain the proposal as if it was implemented and you were teaching it to Kuadrant user. That generally means: - -- Introducing new named concepts. -- Explaining the feature largely in terms of examples. -- Explaining how a user should *think* about the feature, and how it would impact the way they already use Kuadrant. It should explain the impact as concretely as possible. -- If applicable, provide sample error messages, deprecation warnings, or migration guidance. -- If applicable, describe the differences between teaching this to existing and new Kuadrant users. +Make explicit that OCM policy is different to a gateway API policy, and that this work is not related at all to the OCM Policy framework. The policy sync system will allow a gateway-admin to create or modify a gateway class at the hub level and specify a series of GVKs for that gatewayClass (for example the AuthPolicy GVK). @@ -37,26 +35,35 @@ When the AuthPolicies are placed on the relevant spokes, they will be manipulate # Reference-level explanation [reference-level-explanation]: #reference-level-explanation -This is the technical portion of the RFC. Explain the design in sufficient detail that: - -- Its interaction with other features is clear. -- It is reasonably clear how the feature would be implemented. -- How error would be reported to the users. -- Corner cases are dissected by example. - -The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. +### Process overview +- gateway controller updated to monitor params in gateway class +- Set up dynamic watches against each listed GVK + - error when GVK not present - report in gatewayclass + - confirm GVK is a policy - report in gatewayclass if not, don't create watch +- find all matching GVKs that target reconciling gateway +- copy GVK CR into manifestwork for same clusters as gateway + - mutate GVK CR to target the spoke instance of the gateway + - mutate GVK CR to annotate that it came from the hub + - add common policy status fields to manifestwork + - handle error if status fields are not present? +- read status from manifestwork and update status in hub GVK CR +- read errors on gateway if conflicting policies are present in spoke? + +### Policy Hierarchy Details + +- kuadrant operator to encode policy heirarchy + - hub policy overidden by spoke policy overridden by route policy. # Drawbacks [drawbacks]: #drawbacks -Why should we *not* do this? +cluster-admins can already create policies in spoke clusters that affect spoke level gateways, without this solution. # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives -- Why is this design the best in the space of possible designs? -- What other designs have been considered and what is the rationale for not choosing them? -- What is the impact of not doing this? +## Consequences of not implementing +Gateway-admins will have no centralized system for handling spoke-level policies targeting a gateway created there from the hub. #### We will not be using the policy framework to complete this objective: The policy framework is an improvement on the system currently used to place resources on spoke clusters from the hub, essentially removing the need to read the placement decision and manually create manifestworks. @@ -70,29 +77,14 @@ The current proposal, regarding this work, is to proceed with our current manife # Prior art [prior-art]: #prior-art -Discuss prior art, both the good and the bad, in relation to this proposal. -A few examples of what this can include are: - -- Does another project have a similar feature? -- What can be learned from it? What's good? What's less optimal? -- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. - -This section is intended to encourage you as an author to think about the lessons from other tentatives - successful or not, provide readers of your RFC with a fuller picture. - -Note that while precedent set by other projects is some motivation, it does not on its own motivate an RFC. +No applicable prior art. # Unresolved questions [unresolved-questions]: #unresolved-questions -- What parts of the design do you expect to resolve through the RFC process before this gets merged? -- What parts of the design do you expect to resolve through the implementation of this feature before stabilization? -- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? - # Future possibilities [future-possibilities]: #future-possibilities -Think about what the natural extension and evolution of your proposal would be and how it would affect the platform and project as a whole. Try to use this section as a tool to further consider all possible interactions with the project and its components in your proposal. Also consider how this all fits into the roadmap for the project and of the relevant sub-team. - -This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. +If the policy-framework is updated to enable syncing of resources status back to the hub, that could be a good time to refactor the MGC to use the policy framework in place of the current approach of creating manifestworks directly. -Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information. \ No newline at end of file +This system could mutate over time to dynamically sync more CRDs than policies to spoke clusters. \ No newline at end of file From c95987aedf7d979c43563b01a1ba429f00eb4cf3 Mon Sep 17 00:00:00 2001 From: Phil Brookes Date: Fri, 13 Oct 2023 12:51:39 +0100 Subject: [PATCH 3/7] small RFC update --- rfcs/0004-policy-sync-v1.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/rfcs/0004-policy-sync-v1.md b/rfcs/0004-policy-sync-v1.md index d9df8664..fd8fc739 100644 --- a/rfcs/0004-policy-sync-v1.md +++ b/rfcs/0004-policy-sync-v1.md @@ -53,6 +53,7 @@ When the AuthPolicies are placed on the relevant spokes, they will be manipulate - kuadrant operator to encode policy heirarchy - hub policy overidden by spoke policy overridden by route policy. + - annotate gateway when a hub policy is overridden in this manner. # Drawbacks [drawbacks]: #drawbacks @@ -66,13 +67,10 @@ cluster-admins can already create policies in spoke clusters that affect spoke l Gateway-admins will have no centralized system for handling spoke-level policies targeting a gateway created there from the hub. #### We will not be using the policy framework to complete this objective: -The policy framework is an improvement on the system currently used to place resources on spoke clusters from the hub, essentially removing the need to read the placement decision and manually create manifestworks. +The policy framework is a system designed to make assertions about the state of a spoke, and potentially take actions based on that state, as such it is not a suitable replacement for manifestworks in the case of syncing resources to a spoke. -As such, we might want to eventually look at migrating to using the system for all hub > spoke placements. - -However, the policy framework currently has a significant limitation preventing our usecase, which is that we cannot read the status back from the resources created in the spoke. - -The current proposal, regarding this work, is to proceed with our current manifestwork solution, and migrate all hub > spoke placement logic if the policy framework reaches a point that it is more feasible. +### We could eventually migrate from manifestworks to manifestworkreplicasets +Manifestworkreplicasets maybe a future improvement that we could change the MGC to use but not as part of this RFC. # Prior art [prior-art]: #prior-art From 5fc107cd0b338c543f4fe5de32edde737133a6b0 Mon Sep 17 00:00:00 2001 From: Sergio Franco Date: Thu, 2 Nov 2023 09:10:28 +0000 Subject: [PATCH 4/7] Complete Policy sync RFC --- rfcs/0004-policy-sync-v1.md | 157 +++++++++++++++++++++++++++--------- 1 file changed, 121 insertions(+), 36 deletions(-) diff --git a/rfcs/0004-policy-sync-v1.md b/rfcs/0004-policy-sync-v1.md index fd8fc739..0cfa5dcb 100644 --- a/rfcs/0004-policy-sync-v1.md +++ b/rfcs/0004-policy-sync-v1.md @@ -8,69 +8,136 @@ # Summary [summary]: #summary -When a gateway in the hub is targeted by a policy in the hub, enable the gateway controller to be able to sync both the gateway and policy together to spoke clusters. +The ability for the Multicluster Gateway Controller to sync policies defined in +the hub cluster downstream to the spoke clusters, therefore allowing all policies +to be defined in the same place. These policies will be reconciled by the downstream +Gateway controller. + +# Nomenclature + +* Policy: When refering to a Policy, this document is refering to a Gateway API + policy as defined in the Policy Attachment Model. The Multicluster Gateway Controller + relies on [OCM]() as a Multicluster solution, which defines its own unrelated + set of Policies and Policy Framework. Unless explicitely mentioned, this document + refers to Policies as Gateway API Policies. # Motivation [motivation]: #motivation -Currently, any policies targeting gateways in the spokes need to be defined in the spokes, and it can be cumbersome, time-consuming and error prone to require these to be duplicated across multiple spoke clusters. +Currently, Kuadrant's support for the Policy Attachment Model can be divided in +two categories: +* Policies targeting the Multicluster Gateway, defined in the hub cluster and + reconciled by the Multicluster Gateway Controller +* Policies targeting the downstream Gateway, defined in the spoke clusters and + reconciled by the downstream Gateway controllers. -Gateway-admin has a set of homogeneous clusters and needs to apply per cluster rate limits across the entire set. +In a realistic multicluster scenario where multiple spoke clusters are present, the management of these policies can become tedious and error-prone, as policies have +to be defined in the hub cluster, as well as replicated in the multiple spoke clusters. -Platform-admin with a set of clusters with rate limits applied needs to change rate limit for one particular cluster. +As Kuadrant users: +* Gateway-admin has a set of homogeneous clusters and needs to apply per cluster rate limits across the entire set. +* Platform-admin with a set of clusters with rate limits applied needs to change rate limit for one particular cluster. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation -Make explicit that OCM policy is different to a gateway API policy, and that this work is not related at all to the OCM Policy framework. +The policy sync feature will allow a gateway-admin to configure, via GatewayClass +parameters, a set of Policy GVRs to be synced by the Multicluster Gateway Controller. + +The `policiesToSync` field in the parameters defines those GVRs. For example, in +order to configure the controller to sync AuthPolicies: + +```json +"policiesToSync": [ + { + "group": "kuadrant.io", + "version": "v1beta1", + "resource": "authpolicies" + } +] +``` + +The support for resources that the controller can sync is limited by the following: +* The controller ServiceAccount must have permission to watch, list, and get the + resource to be synced +* The resource must implement the Policy schema: + * Have a `.spec.targetRef` field + +When a Policy is configured to be synced in a GatewayClass, the Multicluster +Gateway Controller starts watching events on the resources, and propagates changes +by placing the policy in the spoke clusters, with the following mutations: +* The `TargetRef` of the policy is changed to reference the downstream Gateway +* The `kuadrant.io/policy-synced` annotation is set -The policy sync system will allow a gateway-admin to create or modify a gateway class at the hub level and specify a series of GVKs for that gatewayClass (for example the AuthPolicy GVK). +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation -When a gateway is created in the hub that uses this gatewayClass, any AuthPolicies that target that gateway will be watched by the MGC. +### Process overview -When these gateways are placed on a spoke, any AuthPolicies targeting that gateway will also be placed on that same spoke. +#### Dynamic Policy watches -When the AuthPolicies are placed on the relevant spokes, they will be manipulated to target the new gateway in the spoke. +The Multicluster Gateway Controller reconciles parameters referenced by the +GatewayClass of a Gateway. A new field is added to the parameters that allows +the configuration of a set of GVRs of Policies to be synced. -# Reference-level explanation -[reference-level-explanation]: #reference-level-explanation +The GatewayClass reconciler validates that: +* The GVRs reference existing resource definitions +* The GVRs reference resources that implement the Policy schema. -### Process overview -- gateway controller updated to monitor params in gateway class -- Set up dynamic watches against each listed GVK - - error when GVK not present - report in gatewayclass - - confirm GVK is a policy - report in gatewayclass if not, don't create watch -- find all matching GVKs that target reconciling gateway -- copy GVK CR into manifestwork for same clusters as gateway - - mutate GVK CR to target the spoke instance of the gateway - - mutate GVK CR to annotate that it came from the hub - - add common policy status fields to manifestwork - - handle error if status fields are not present? -- read status from manifestwork and update status in hub GVK CR -- read errors on gateway if conflicting policies are present in spoke? - -### Policy Hierarchy Details - -- kuadrant operator to encode policy heirarchy - - hub policy overidden by spoke policy overridden by route policy. - - annotate gateway when a hub policy is overridden in this manner. +Validation failures are reported as part of the status of the GatewayClass + +The Gateway reconciler sets up dynamic watches to react to events on the configured +Policies, calling the PolicySyncer component with the updated Policy as well +as the associated Gateway. + +#### PolicySyncer component + +The PolicySyncer component is in charge of reconciling Policy watch events to +apply the necessary changes and place the Policies in the spoke clusters. + +This component is injected in the event source and called when a change is made +to a hub Policy that has been configured to be synced. + +The PolicySyncer implementation uses OCM ManifestWorks to place the policies in +the spoke clusters. Through the ManifestWorks, OCM allows to: +* Place the Policy in each spoke cluster +* Report the desired status back to the hub using JSON feedback rules + +### Policy Hierarchy + +In order to avoid conflict with Policies created directly in the spoke clusters, +a hierarchy must be defined to prioritise those Policies. + +The controller will set the `kuadrant.io/policy-synced` annotation on the policy +when placing it in the spoke cluster. + +The Kuadrant operator will be aware of the presence of this annotation, and, in case +of conflicts, override Policies that contain this annotation. # Drawbacks [drawbacks]: #drawbacks -cluster-admins can already create policies in spoke clusters that affect spoke level gateways, without this solution. +## Third party Policy support + +In order for a Policy to be supported for syncing, the MGC must have permissions +to watch/list/get the resource, and the implementation of the downstream Gateway +controller must be aware of the `policy-synced` annotation. # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives ## Consequences of not implementing + Gateway-admins will have no centralized system for handling spoke-level policies targeting a gateway created there from the hub. -#### We will not be using the policy framework to complete this objective: -The policy framework is a system designed to make assertions about the state of a spoke, and potentially take actions based on that state, as such it is not a suitable replacement for manifestworks in the case of syncing resources to a spoke. +#### OCMs Policy Framework will not be used to complete this objective: + +OCMs Policy Framework is a system designed to make assertions about the state of a spoke, and potentially take actions based on that state, as such it is not a suitable replacement for manifestworks in the case of syncing resources to a spoke. + +### Potential migration from ManifestWorks to ManifestWorkReplicaSets -### We could eventually migrate from manifestworks to manifestworkreplicasets -Manifestworkreplicasets maybe a future improvement that we could change the MGC to use but not as part of this RFC. +ManifestWorkPeplicaSets may be a future improvement that the MGC could support +to simplify the placement of related resources, but beyond the scope of this RFC. # Prior art [prior-art]: #prior-art @@ -80,9 +147,27 @@ No applicable prior art. # Unresolved questions [unresolved-questions]: #unresolved-questions +## Status reporting + +While the controller can assume common status fields among the Policies that it +syncs, there might be a scenario where certain policies use custom status fields +that are not handled by the controller. In order to support this, two alternatives +are identified: + +1. Configurable rules. + + An extra field is added in the GatewayClass params that configures the policies + to sync, to specify custom fields that the controller must propagate back from + the spokes to the hub. + +2. Hard-coded support. + + The PolicySync component can identify the Policy type and select which extra + status fields are propagated + # Future possibilities [future-possibilities]: #future-possibilities -If the policy-framework is updated to enable syncing of resources status back to the hub, that could be a good time to refactor the MGC to use the policy framework in place of the current approach of creating manifestworks directly. +If OCMs Policy Framework is updated to enable syncing of resources status back to the hub, it could be an opportunity to refactor the MGC to use this framework in place of the current approach of creating ManifestWorks directly. This system could mutate over time to dynamically sync more CRDs than policies to spoke clusters. \ No newline at end of file From f5e271951182c9228298aa3367ad14305c80c9b1 Mon Sep 17 00:00:00 2001 From: Sergio Franco Date: Tue, 14 Nov 2023 14:47:21 +0000 Subject: [PATCH 5/7] Addressing comments --- rfcs/0004-policy-sync-v1.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/rfcs/0004-policy-sync-v1.md b/rfcs/0004-policy-sync-v1.md index 0cfa5dcb..4f5b4ff8 100644 --- a/rfcs/0004-policy-sync-v1.md +++ b/rfcs/0004-policy-sync-v1.md @@ -11,16 +11,18 @@ The ability for the Multicluster Gateway Controller to sync policies defined in the hub cluster downstream to the spoke clusters, therefore allowing all policies to be defined in the same place. These policies will be reconciled by the downstream -Gateway controller. +policy controller(s). # Nomenclature * Policy: When refering to a Policy, this document is refering to a Gateway API policy as defined in the Policy Attachment Model. The Multicluster Gateway Controller - relies on [OCM]() as a Multicluster solution, which defines its own unrelated + relies on [OCM](https://open-cluster-management.io/) as a Multicluster solution, which defines its own unrelated set of Policies and Policy Framework. Unless explicitely mentioned, this document refers to Policies as Gateway API Policies. +* Policy overriding: The concept of policy overriding is mentioned in this document. It refers to the proposed ability of the downstream Gateway implementation to prioritise downstream Policies against synced Policies in case of conflicts. + # Motivation [motivation]: #motivation @@ -126,6 +128,13 @@ controller must be aware of the `policy-synced` annotation. # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives +## Alternatives + +Different technology stacks are available to sync resources across clusters. However, adoption of these technologies for the purpose of the goal this RFC intends to achieve, implies adding another dependency to the current stack, with the cost of added complexity and maintainance effort. + +The MGC currently uses OCM to place Gateways across clusters. Relying on OCM for the purpose of placing Policies is the most straightforward alternative from a design and implementation point of view. + + ## Consequences of not implementing Gateway-admins will have no centralized system for handling spoke-level policies targeting a gateway created there from the hub. From b1789ab7cd0774c6b717f51971fc0a4b1fd08a10 Mon Sep 17 00:00:00 2001 From: Sergio Franco Date: Wed, 29 Nov 2023 10:29:31 +0000 Subject: [PATCH 6/7] Addressing suggestions --- .gitignore | 1 - rfcs/0004-policy-sync-v1.md | 12 +++++++++++- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index 485dee64..e69de29b 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +0,0 @@ -.idea diff --git a/rfcs/0004-policy-sync-v1.md b/rfcs/0004-policy-sync-v1.md index 4f5b4ff8..b0f5cf4f 100644 --- a/rfcs/0004-policy-sync-v1.md +++ b/rfcs/0004-policy-sync-v1.md @@ -71,6 +71,13 @@ by placing the policy in the spoke clusters, with the following mutations: * The `TargetRef` of the policy is changed to reference the downstream Gateway * The `kuadrant.io/policy-synced` annotation is set +The upstream policy is annotated with a reference to the name and namespace +of the downstream policies: + ```yaml + annotations: + "kuadrant.io/policies-synced": "[{\"cluster\": \"...\", \"name\": \"...\", \"namespace\": \"...\"}]" + ``` + # Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -114,7 +121,10 @@ The controller will set the `kuadrant.io/policy-synced` annotation on the policy when placing it in the spoke cluster. The Kuadrant operator will be aware of the presence of this annotation, and, in case -of conflicts, override Policies that contain this annotation. +of conflicts, override Policies that contain this annotation. When a policy is +overriden due to conflicts, the `Enforced` status will be set to `False`, with +the reason being `Overriden` and a human readable message explaining the reason +why the policy was overriden. See [Policy Status RFC](./0004-policy-status.md) # Drawbacks [drawbacks]: #drawbacks From 868d978c74bb2f2f4d7363d1bfba5f1a3474be6f Mon Sep 17 00:00:00 2001 From: Sergio Franco Date: Wed, 29 Nov 2023 10:30:29 +0000 Subject: [PATCH 7/7] Updating files from rebase --- .gitignore | 0 rfcs/{0004-policy-sync-v1.md => 0007-policy-sync-v1.md} | 0 2 files changed, 0 insertions(+), 0 deletions(-) delete mode 100644 .gitignore rename rfcs/{0004-policy-sync-v1.md => 0007-policy-sync-v1.md} (100%) diff --git a/.gitignore b/.gitignore deleted file mode 100644 index e69de29b..00000000 diff --git a/rfcs/0004-policy-sync-v1.md b/rfcs/0007-policy-sync-v1.md similarity index 100% rename from rfcs/0004-policy-sync-v1.md rename to rfcs/0007-policy-sync-v1.md