kubernetes-sigs
Conformance tests for HTTPRouteFilterURLRewrite on BackendRef
What type of PR is this?
/kind test /area conformance-test
What this PR does / why we need it: Adds conformance tests for HTTPRouteFilterURLRewrite on the BackendRef for Host, Host+Weights, Host+Headers, Path, Path+Weights, Path+Headers. There was no coverage for HTTPRouteFilterURLRewrite on BackendRef.
Which issue(s) this PR fixes:
Fixes #2937
Does this PR introduce a user-facing change?:
NONE
Hi @chris-kaiser-7. 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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
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-sigs/prow repository.
I tested this with envoy implementation. Envoy had a validation check preventing this. I removed the validation check but the test still failed. I guess envoy doesn't support this. I am going to try on other implementations tho.
I tested this with envoy implementation. Envoy had a validation check preventing this. I removed the validation check but the test still failed. I guess envoy doesn't support this. I am going to try on other implementations tho.
Unfortunately, I think it will be hard to find an implementation that supports this today. Recommend asking in #sig-network-gateway-api Slack channel.
Should I add a new features such as SupportHTTPRouteHostRewriteBackend for this? or is SupportHTTPRouteHostRewrite sufficient.
Should I add a new features such as SupportHTTPRouteHostRewriteBackend for this? or is SupportHTTPRouteHostRewrite sufficient.
Yes, we should have a separate feature, and that looks like a good feature name for this.
The purpose here is to allow implementations that can't or don't want to do this to opt out.
(This will be difficult to impossible for Envoy-based implementations).
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: chris-kaiser-7 Once this PR has been reviewed and has the lgtm label, please assign aojea for approval. For more information see the Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
@chris-kaiser-7 Given the current thinking about this being difficult or impossible to implement in Envoy currently, is there an implementation you've found that is currently able to support this feature to exercise these conformance tests?
@chris-kaiser-7 Given the current thinking about this being difficult or impossible to implement in Envoy currently, is there an implementation you've found that is currently able to support this feature to exercise these conformance tests?
@mikemorris So I tested this in envoy and in NGF and they both failed. I tried removing the validations in envoy just to see if it would work but it still failed. I don't think it will pass in any current implementation?
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle stale - Close this PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
