-
Notifications
You must be signed in to change notification settings - Fork 498
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
implement GEP-820: remove extension points from route match types #829
implement GEP-820: remove extension points from route match types #829
Conversation
59bc62c
to
cf8564d
Compare
GEP merged. |
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.
This looks good overall, as per the GEP. Preserving the match field but disallowing its use seems a bit strange, but I can see why you went there.
Maybe we should take an issue to remove the match field for the release?
/lgtm
/hold
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hbagdi, jpeach The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
apis/v1alpha2/tcproute_types.go
Outdated
// | ||
// +optional | ||
// +kubebuilder:validation:MaxItems=8 | ||
// +kubebuilder:validation:MaxItems=0 |
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 think it may be better to just remove the matches field entirely until we add content to them. I think that would actually make our L4 routes easier to understand.
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 was conflicted. Erroring towards conservative side.
This may confuse users who try to create types by copying the art here. Let's take that risk.
cf8564d
to
4b6943e
Compare
4b6943e
to
e3450f7
Compare
/lgtm I think that this is a good change, and that removing the match functionality makes TCPRoute and UDPRoute easier to explain, at least initially. |
Thanks! /lgtm |
Based on our discussion at the community meeting yesterday, I think we have sufficiently broad consensus to remove the hold on this. /hold cancel |
In commit c7bb1d6 (kubernetes-sigs#808), we documented how the tcp route match extension point can be used for metadata based tcp matching. Soon after, in commit e3450f7 (kubernetes-sigs#829), this extension point was removed, but the docs remained. Remove this section to reflect the current state of the API.
What type of PR is this?
/kind api-change
What this PR does / why we need it:
Implements GEP #820 Drop extension points from Route matches
Which issue(s) this PR fixes:
Fixes #820
Does this PR introduce a user-facing change?:
GEP isn't merged (#822).
/hold