-
Notifications
You must be signed in to change notification settings - Fork 33
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
ratelimitpolicy v1beta3 #875
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #875 +/- ##
==========================================
+ Coverage 80.20% 81.30% +1.09%
==========================================
Files 64 102 +38
Lines 4492 7089 +2597
==========================================
+ Hits 3603 5764 +2161
- Misses 600 897 +297
- Partials 289 428 +139
Flags with carried forward coverage won't be shown. Click here to find out more.
|
0fe564a
to
125a5ff
Compare
api/v1beta3/ratelimitpolicy_types.go
Outdated
@@ -141,7 +141,7 @@ type RateLimitPolicySpec struct { | |||
// TargetRef identifies an API object to apply policy to. | |||
// +kubebuilder:validation:XValidation:rule="self.group == 'gateway.networking.k8s.io'",message="Invalid targetRef.group. The only supported value is 'gateway.networking.k8s.io'" | |||
// +kubebuilder:validation:XValidation:rule="self.kind == 'HTTPRoute' || self.kind == 'Gateway'",message="Invalid targetRef.kind. The only supported values are 'HTTPRoute' and 'Gateway'" | |||
TargetRef gatewayapiv1alpha2.LocalPolicyTargetReference `json:"targetRef"` | |||
TargetRef gatewayapiv1alpha2.LocalPolicyTargetReferenceWithSectionName `json:"targetRef"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mind keeping this one commit out if this PR please? It's done in #893 where it makes more sense IMO, because the functionality for it is also implemented there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need that to implement the removal of routeSelectors. It's part of my assignment on #810
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please. Don't do that either. It's also removed in #893, along with the meaning of that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am confused. I thought we agreed on doing the version bumping first together with the route selector removal. That's a change big enough to deserve it's own PR. Then in another PR, the refactor on the state of the world controller.
I think it is reasonable and we should stick to the plan.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can remove the routeSelectors in its own PR if you prefer (although not here), but either way adding the sectionName has no meaning without the task the computes the effect RLPs.
Please refer to #893 to see what's in there. Hopefully it will make more sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
adding the sectionName has no meaning without the task the computes the effect RLPs.
Completely disagree. Adding the sectionName and removing the routeSelectors is itself the point of this PR. And it can be done without computing the effective policies and without refactor to to the state of the world controller
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eguzki, I see your point, but we are doing the same work twice. The work in #893 is done already, and that branch targets this one in case you want to merge it in one go.
Redoing the same thing in this PR is a waste of your time IMO, first because it's done in there and it will all be part of the same change anyway, but more importantly to me because here it would be a change to the API without the counterpart function that uses this field.
That said, if you really want to work on some part of this particular change still in this PR, the only thing I ask is please do not add sectionName
just yet. You can remove routeSelectors
and all the logic related to it. I'm fine with rebasing mine. Np.
With all due respect, @guicassolato, do not change the scope of the issues that we had agree upon in the planning stage on your own. That's not nice. You could be doing some work that someone else had already done because it was enclosed on another issue. That's wasting someones time. I will remove all the changes that you already did and open PR with only the version bump. |
I see where you are coming from. Indeed "Add In the end, many of these tasks are convoluted I'm afraid. There's very little left to merging policies together without the sectionName and there is no reason to introduce sectionName other than for changing how we let policies target sections of the resources and consequently how we merge policy specs that add definitions only for those sections. IOW, sectionName and effective policies with D&O and merge strategies in context are all mixed together into one. Unfortunately, the issues in GitHub do not do a great job at setting clearly the boundaries of what's one thing and what's another, especially in this case where lines are in fact blurred. We need more human communication to sync on this kind of stuff IMO. Apologies if you have perceived as a change of plans. It was never my intention. I'm only trying to be proactive here. Last week we agreed on working on this part of the workflow together. You were kind enough to share a draft. I wanted to add the next bit. |
125a5ff
to
4cef480
Compare
ready for rewiew @guicassolato |
0152aa5
to
57d555b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just need to sort out those couple unit tests failing due to now seeing the hostnames in the conditions to call the RL service, but the general change LGTM. In fact, very thorough job on removing the routeSelectors
. Thank you, @eguzki!
57d555b
to
baf6e08
Compare
Signed-off-by: Eguzki Astiz Lezaun <eastizle@redhat.com>
Signed-off-by: Eguzki Astiz Lezaun <eastizle@redhat.com>
Signed-off-by: Eguzki Astiz Lezaun <eastizle@redhat.com>
Signed-off-by: Eguzki Astiz Lezaun <eastizle@redhat.com>
Signed-off-by: Eguzki Astiz Lezaun <eastizle@redhat.com>
Signed-off-by: Eguzki Astiz Lezaun <eastizle@redhat.com>
Signed-off-by: Eguzki Astiz Lezaun <eastizle@redhat.com>
Signed-off-by: Eguzki Astiz Lezaun <eastizle@redhat.com>
Signed-off-by: Eguzki Astiz Lezaun <eastizle@redhat.com>
Signed-off-by: Eguzki Astiz Lezaun <eastizle@redhat.com>
45f6211
to
bb71440
Compare
rebase to resolve conflicts required and fixed integration tests. please review @guicassolato Thanks 🙇♀️ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat.
No description provided.