api

api copied to clipboard

We have a use case to pick the rewritten header using regex when header based consistent hash is used. Envoy supports this. It is very difficult to craft an Envoy filter for this (need to replace the entire virtual host)

@ramaraochavali: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
release-notes_api	0413bfcd3c30628bb6eb4e25342c0b740850d871	link	false	/test release-notes

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 understand the commands that are listed here.

@whitneygriffith

https://www.envoyproxy.io/docs/envoy/v1.30.1/api-v3/config/route/v3/route_components.proto.html#envoy-v3-api-msg-config-route-v3-routeaction-hashpolicy-header - Its been there for a while in Envoy

TLDR to add a new field to a v1 API:

• Add // +cue-gen:DestinationRule:releaseChannel:extended tag to the proto definition similar to what was done here to all API versions.
• Update the stable validation policy to exclude the new field in the following manifests: base chart and istio-discovery chart

CC: @keithmattix

Does it not work in envoy to do a normal header rewrite and use that as a key?

Does it not work in envoy to do a normal header rewrite and use that as a key?

What do you mean by normal header rewrite?

I mean just a standard http header rewrite in virtual service

On Wed, May 8, 2024, 8:46 PM Rama Chavali @.***> wrote:

Does it not work in envoy to do a normal header rewrite and use that as a key?

What do you mean by normal header rewrite?

— Reply to this email directly, view it on GitHub https://github.com/istio/api/pull/3180#issuecomment-2101879022, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEYGXJ3GCWOGVDRMVJMBJ3ZBLWP7AVCNFSM6AAAAABHM2NGEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBRHA3TSMBSGI . You are receiving this because your review was requested.Message ID: @.***>

No. We need just rewrite the header using regex capture groups (specifically path header) and use it as hash key but not rewrite the value of the header. Also there is no generic regex rewrite for headers in VS?

I see. I worry this usage is extraordinarily niche. Consistent hash AND rewrite AND regex capture... this really feels like something best outside of core of Istio

I also tried to solve this with Envoy filter but the filter means we need to replace the entire vhost/route which is not ideal.

Maybe you can insert some custom filter that does some manipulation before the hashing runs

My suggestion is to see if we can improve EnvoyFilter to make it easy to support this case.

Did anyone check the EnvoyGateway equivalent of EnvoyPatchPolicy - basically json patch ? Would something like that work for this case ( so we don't reinvent the wheel ) ?

PR needs rebase.

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.