-
Notifications
You must be signed in to change notification settings - Fork 474
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
DNM: Poc rustformations sidebyside #10677
base: main
Are you sure you want to change the base?
Conversation
made tilt work again. try it! ``` ctlptl create cluster kind --name kind-kgateway --registry=ctlptl-registry VERSION=1.0.0-ci1 CLUSTER_NAME=kgateway IMAGE_VARIANT=standard make kind-build-and-load tilt up ``` also made tcprotues a delayed informer so we will start if they are not there.
|
||
for (key, value) in &self.request_headers_setter { | ||
let mut env = self.env.clone(); | ||
env.add_template("temp", value).unwrap(); |
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.
add_template can fail so ideally we want to do it at config time so envoy NACKs it.. do you know if that's possible?
}; | ||
let value = std::str::from_utf8(val.as_slice()).unwrap().to_string(); | ||
|
||
headers.insert(key.to_string(), value); |
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.
we copy all the headers all the time? this could potentially have perf issues; current impl only copies the header when it is requested by user - is that achievable?
This PR solely serves to illustrate how we could start migrating off of envoy-gloo into using purely envoyproxy/envoy builds while still being able to extend functionality that gloo users used heavily. This approach relies heavily on the new dynamic_modules examples (https://github.com/envoyproxy/dynamic-modules-examples/tree/main/rust)
In order to have old envoy-gloo functionality work side by side for best effect this also includes bumping envoy-gloo to be on an envoy version post 1.33 which has workable dynamic modules.
Note that this exists to be referenced in the upcoming EP where data plane changes will be proposed to promote vendor neutrality and therefore work to not rely on envoy-gloo repository.