-
Notifications
You must be signed in to change notification settings - Fork 472
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
api: remove ListenerReasonRouteConflict #1145
api: remove ListenerReasonRouteConflict #1145
Conversation
This appears to be an artifact of the v1alpha1 configuration style where a listener selects routes. In v1alpha2 an unsupported route should instead be rejected by the gateway, and optionally set an Accepted RouteCondition with status False.
Hi @mikemorris. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
Thanks! /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mikemorris, robscott 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 |
What type of PR is this?
/kind cleanup
/kind documentation
/kind api-change
/kind deprecation
What this PR does / why we need it:
This appears to be an artifact of the v1alpha1 configuration style where a listener selects routes directly. In v1alpha2 an unsupported route attempting to attach to a listener should instead be rejected by the gateway, and optionally set an
Accepted
RouteCondition with statusFalse
.A somewhat-related mismatch between the Listener's
AllowedRoutes
kinds
field and the supportedprotocol
is explicitly expected to be expressed by theResolvedRefs
ListenerCondition setting statusFalse
with theInvalidRouteKinds
reason (but could possibly be covered instead by webhook validation for the Core support level ProtocolType values and xRoute kinds?)Which issue(s) this PR fixes:
Refs #1077, #935 (comment)
Does this PR introduce a user-facing change?: