design 10574: transformations #10689
Conversation
Co-authored-by: Jenny Shu <[email protected]>
design/10574.md
Outdated
|
|
||
|
|
||
| ## Alternatives | ||
| Port the existing Transformation from the old project and figure out how to migrate the custom envoy to github actions. |
There was a problem hiding this comment.
migrate the custom envoy to github actions
can you clarify what this means? i.e. getting CI for a custom envoy build working?
There was a problem hiding this comment.
Does the update better answer?
|
|
||
| ## Open Questions | ||
| What is the timeline to removal of the current extended envoy image. | ||
| How do we want to handle route level overrides. |
There was a problem hiding this comment.
do we know if upstream has plans for it?; otherwise check if using the composite filter solves it?
There was a problem hiding this comment.
I dont see it currently see a reference to route level configuration but i also see that filter registration factory is delegated to the dynamic module implementation so may try something out.
| // +listMapKey=name | ||
| // +kubebuilder:validation:MaxItems=16 | ||
| Add []HeaderTransformation `json:"add,omitempty"` | ||
There was a problem hiding this comment.
for completeness should we also have remove?
| * Allow for mutations that are based on the contents of the request / response | ||
| * Have transformations support be stabley defined and not require a network hop | ||
| * Have an opinionated api to keep functionality be locked to transforming envoy constructs such as filter state, headers, body, trailers and metadata | ||
| * Keep all kgateway implementation specifics in kgateway repository. |
There was a problem hiding this comment.
how common is the use case of using values from the body for routing? if its common, should we support it at the first stage? (i'm ok deferring this, if you think that's ok)
There was a problem hiding this comment.
In my experience its only used a small portion of the time.
| type MetadataTransformation struct { | ||
| // +required | ||
| Namespace string `json:"name,omitempty"` |
There was a problem hiding this comment.
i assume this is envoy dynamic-metadata filter namespace, not k8s namespace?
There was a problem hiding this comment.
Yep. In my opinion having the policy have a nested construct that has the word metadata in it made the field of Namespace feel better as it doesnt stutter but am happy to change it if people feel that having the disambiguation would be nicer.
| * Allow for mutations that are based on the contents of the request / response | ||
| * Have transformations support be stabley defined and not require a network hop | ||
| * Have an opinionated api to keep functionality be locked to transforming envoy constructs such as filter state, headers, body, trailers and metadata | ||
| * Keep all kgateway implementation specifics in kgateway repository. |
There was a problem hiding this comment.
Just to clarify: this means the rust code would live in-tree instead of a dedicated repo, right? That would be consistent with the direction we wanted to take with the ext-proc implementation needed by the AI functionality (afaik).
There was a problem hiding this comment.
Exactly. I dont want to have to look multiple places for code that makes decisions in the gateway
| ### Goals | ||
| * Allow for extraction of data from a header and place it in dynamic metadata or filter state such that it can be pulled into access logs | ||
| * Allow for mutations that are based on the contents of the request / response | ||
| * Have transformations support be stabley defined and not require a network hop |
There was a problem hiding this comment.
not blocking: s/stabely/stably?
Just for my own edification, the network hop here is alluding to doing this all via native (i.e. compiled?) envoy filters vs. having to call out to external components, e.g. custom ext-authz servers for authn/authz flows.
There was a problem hiding this comment.
Basically why we should make this a first class citizen rather than say just ask users to build their own ext proc servers
Adds a proposal to allow for access log enrichment via headers and the ability to make comlex substitutions to headers on a request/response.
Current idea is to end up with a repo structure along the lines of this