Adding Route Delegation Details for each HTTPRoute Capability #1300
Conversation
|
Skipping CI for Draft Pull Request. |
k8s-ci-robot
added
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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 |
k8s-ci-robot
added
the
approved
| | Prefix Path on Parent, Prefix or Exact on Child | High | Low | Prefix path match of parent is prepended to child path match, child can support exact or prefix path matching | | ||
| | Exact Path on Parent | Low | Moderate | Would require only "/" matches on child route | | ||
| | Exact Path on Child | High | Low | Prefix path match of parent is prepended to child path match, child can support exact or prefix path matching | | ||
| | Regex Path on Parent or Child | Low | Impossible | Maybe some complex merging is possible here, but I can't think of a good solution | |
There was a problem hiding this comment.
What about delegating something like a /accounts/[id] pattern? This feels like it may be not a not-uncommon need - could something like excluding a parent PathPrefix make this possible? RegEx parent path feels like it could be harder and lower-value though, maybe split these cases apart?
| * Does the child route match `/foo/bar` and `/bar/baz`? | ||
| * Would it be preferable to require the child route to specify the full path? | ||
| * How does this interact with potential matching conflicts for headers or query params? |
There was a problem hiding this comment.
I think matching both makes sense, and it's preferable to not specify the full path, as it would make config more brittle if the upstream path were to ever change.
| - prefix: /baz | ||
| ``` | ||
|
|
||
| * Does this only match `GET /foo/baz`? |
There was a problem hiding this comment.
I think yes, it should only match GET /foo/baz (effectively a logical AND evaluation). I think it would make sense to apply the same AND logic to headers and query params, for consistency with the existing intra-match spec https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io%2fv1alpha2.HTTPRouteMatch
|
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
lifecycle/rotten
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
|
@k8s-triage-robot: Closed this PR. In response to this:
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. |
What type of PR is this?
/kind gep
What this PR does / why we need it:
This is meant to augment @Jeff-Apple's primary PR for this GEP (#1085). This PR will likely not merge independently and is still a WIP.
Does this PR introduce a user-facing change?: