Conversation
Signed-off-by: Alice Wasko <alicewasko@datawire.io>
Codecov Report
@@ Coverage Diff @@
## main #1961 +/- ##
==========================================
+ Coverage 65.37% 65.69% +0.31%
==========================================
Files 90 92 +2
Lines 13377 13743 +366
==========================================
+ Hits 8745 9028 +283
- Misses 4092 4166 +74
- Partials 540 549 +9
|
It's awesome! I need similar validation for SecurityPolicy as well. |
| } | ||
|
|
||
| // Check if any policies that target xRoute resources are overriding this policy so we can set the status | ||
| if _, ok := overriddenPolicyTargets[*gatewayKey]; ok { |
There was a problem hiding this comment.
A policy targeting a xRoute does not always override a policy targeting a listener under the same gateway. For example, they may have different hostnames.
There was a problem hiding this comment.
the sectionName of the parentReference is not being saved in L107 so we dont know for sure if this listener section is a parent of the xRoute which has a policy targeted to it
| message, | ||
| ) | ||
| } | ||
|
|
There was a problem hiding this comment.
We should also check if there are existing policies at the route level.
There was a problem hiding this comment.
I believe this is happening on L109
There was a problem hiding this comment.
L109 overriddenPolicyTargets is only used to check conflicts with listeners at L152. Ideally, we should also check if there are existing policies at the route level that override the gateway-level(Policies targeting gateway without sectionname) policies.
| ) | ||
|
|
||
| // +kubebuilder:object:root=true | ||
| // +kubebuilder:resource:shortName=btpolicy |
| // spec defines the desired state of BackendTrafficPolicy. | ||
| type BackendTrafficPolicySpec struct { | ||
|
|
||
| // +kubebuilder:validation:XValidation:rule="has(self.sectionName) ? self.kind == 'Gateway': true", message="sectionName can only be set when kind is 'Gateway'." |
There was a problem hiding this comment.
thanks for adding these !
raised #1964 to add validation tests
| // is being attached to. | ||
| // This Policy and the TargetRef MUST be in the same namespace | ||
| // for this Policy to have effect and be applied to the Gateway. | ||
| TargetRef gwapiv1a2.PolicyTargetReferenceWithSectionName `json:"targetRef"` |
There was a problem hiding this comment.
we should add a line here about policy hierarchy as well as policy override i.e.
- Only one policy can be successfully attached to a specific target
- Since multiple policies can be indirectly applied to the same target e.g. a policy targeting a Gateway as well as a policy targeting a xRoute attached to the same Gateway, the policy with the most specific target will always have higher precedence (in this case the policy targeting the xRoute) over the less specific one (the policy targeting the Gateway)
| if parentRef.Namespace != nil { | ||
| namespace = string(*parentRef.Namespace) | ||
| } | ||
| overriddenPolicyTargets[types.NamespacedName{ |
There was a problem hiding this comment.
can you explain this logic ?
There was a problem hiding this comment.
nvm, looks like we are proactively making sure the parent gateways are overridden, a comment here would be great
|
|
||
| // Process the policies targeting Gateways with a section name | ||
| for _, policy := range backendTrafficPolicies { | ||
| if policy.Spec.TargetRef.SectionName != nil { |
There was a problem hiding this comment.
in theory a route will never reach here because of the CEL validation in the CRD, but this maybe hard for the next dev looking at this to figure that out
can we add an extra checking in here
policy.Spec.TargetRef.Kind == KindGateway && .....
| targetNs = ptr.To(gwv1b1.Namespace(policy.Namespace)) | ||
| } | ||
|
|
||
| // Ensure Policy and target are in the same namespace |
There was a problem hiding this comment.
curious if this can be moved to CEL Validation, not a blocker, we can raise a GH issue to track this
| for _, parentGW := range httpRoute.Spec.ParentRefs { | ||
| key := types.NamespacedName{Name: string(parentGW.Name)} | ||
| if parentGW.Namespace != nil { | ||
| key.Namespace = string(*parentGW.Namespace) |
There was a problem hiding this comment.
when parentGW.Namespace == nil , key.Namespace = httpRoute.Namespace and the same is true for all other route types
| gateways := t.GetRelevantGateways(resources.Gateways) | ||
|
|
||
| // Get Routes belonging to our GatewayClass. | ||
| routes := t.GetRelevantRoutes(gateways, |
There was a problem hiding this comment.
I dont think this is needed, L160-L170 already compute the relevant routes today e.g.
gateway/internal/gatewayapi/route.go
Line 63 in 2ecc54d
we just need to append it into a list and pass it over
| return relevant | ||
| } | ||
|
|
||
| func (t *Translator) GetRelevantRoutes(relevantGateways []*GatewayContext, |
There was a problem hiding this comment.
as shared above, dont think this func is needed
| name: default-ipv-policy | ||
| namespace: default | ||
| spec: | ||
| protocols: |
There was a problem hiding this comment.
can we use a different feature as an example, maybe load balancing
ipv6 routing is tied to L3 which EG cannot really control, it can only make sure that if ipv6 endpoints exist, it can successfully fetch it and program it
| - Policy A will be applied/attached to the specific Listener defined in the `targetRef.SectionName` | ||
| - Policy B will be applied to the remaining Listeners within the Gateway. Policy B will have an additional | ||
| status condition `Overridden=True`. | ||
|
|
There was a problem hiding this comment.
needs another line about policy hierarchy/precendance ( Route > Listener > Gateway)
| targetedRoutes[routeKey] = true | ||
| route := routeMap[*target] | ||
| for _, parentRef := range GetParentReferences(route) { | ||
| namespace := "" |
There was a problem hiding this comment.
should default to namespace of the route
There was a problem hiding this comment.
|
this PR is close to the finish line, thanks for complementing the policy hierarchy complexity with test cases, added some comments, ptal |
|
also 2 more things needed in this PR is
|
Takes PR envoyproxy#1961 forward Signed-off-by: Arko Dasgupta <arko@tetrate.io>
|
closed in favor of #2053 |
* feat BackendTrafficPolicy Takes PR #1961 forward Signed-off-by: Arko Dasgupta <arko@tetrate.io> * lint Signed-off-by: Arko Dasgupta <arko@tetrate.io> * k8s status Signed-off-by: Arko Dasgupta <arko@tetrate.io> * k8s watch Signed-off-by: Arko Dasgupta <arko@tetrate.io> * Update site/content/en/latest/design/backend-traffic-policy.md Co-authored-by: zirain <zirain2009@gmail.com> Signed-off-by: Arko Dasgupta <arkodg@users.noreply.github.com> * Update site/content/en/latest/design/backend-traffic-policy.md Co-authored-by: zirain <zirain2009@gmail.com> Signed-off-by: Arko Dasgupta <arkodg@users.noreply.github.com> --------- Signed-off-by: Arko Dasgupta <arko@tetrate.io> Signed-off-by: Arko Dasgupta <arkodg@users.noreply.github.com> Co-authored-by: zirain <zirain2009@gmail.com>
Initializes the
BackendTrafficPolicycustom resource and API.I added some extra CRD validation to catch a couple things early instead of waiting to get to the runtime condition checks.
Here's some screenshots from when I was working on that so you can get an idea of what a user might see when trying to apply and fix an invalid resource. I'm happy to open a PR tweaking the existing ClientTrafficPolicy CRD to have similar validation if we're good with it.