gateway-api
gateway-api copied to clipboard
About protocol conversion rules
What would you like to be added: I want to discuss protocol conversion at here. It is very common on many gateways. For example gloo edge has a grpc-to-rest feature. Although now we can add a custom backend which specify grpc service and method. However, we can not customize the conversion rules on a specific HttpRoute such as mapping a rest's path parameter to a protobuf's body field.
Why this is needed:
This may be suitable to create some filters to do this.
@tokers Do you mean to create some custom filters? I not found a way to pass parameters at HttpRoute level to a custom filter.
Take a look at filters here: https://gateway-api.sigs.k8s.io/v1alpha2/api-types/httproute/?h=requesth#filters-optional
You can run inline logic to modify requests/responses as they are matched to an HTTPRoute and flow through a Gateway.
One idea to explore in this area is different kinds of backend. You might be able to model GRPC conversion as a CRD type that can be targeted as a backend by a HTTPRoute.
There had been some discussion around potentially adding a GRPCRoute earlier, I think @gnossen had proposed that originally? It would end up being very similar to HTTPRoute, just with different matching. Maybe there's some overlap between this and #920?
@robscott I am not making the gateway to route grpc requests. The request's protocol is rest protocol. Gateway route http requests and convert rest protocol to grpc protocol. In my opinion, I support @jpeach 's idea now.
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:
- 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 issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/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:
- 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 issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/remove-lifecycle rotten
Once we decide what we do with #1004, we will have a place to start from to discuss REST-to-gRPC translation.
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:
- 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 issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale /lifecycle frozen
Despite this issue being quite old, we the maintainers are still pretty convinced that we want to have this functionality in a future release. We are marking this help wanted as we're looking for contributors with strong use cases to help champion and drive this forward.
I wonder if protocol conversion is part of the scope of https://github.com/kubernetes-sigs/gateway-api/pull/1333
I think there's definitely some bits of #1333 and GEP-1282s that affect it, yeah. Let's make a note to come back and check this once we're done with GEP-1282?
@youngnick with #1333 merged, it seems we just need to capture the desire here in that GEP in an upcoming iteration to consider this resolve, yes?
Actually, #1333 and #1282 are actually basically "Declined" as they are now - I'll make a note to update the GEP accordingly. (That's the BackendProperties GEP for those of you playing at home).
I think that we'll need to handle this is some other way, so sadly this one will need to stick around.
I think that we'll need to handle this is some other way, so sadly this one will need to stick around.
What's the impetus for handling this right now? Given the age and the lack of someone to champion and move it forward wouldn't it be better to consider this one closed (keeping in mind that closed does not mean we will never work on it, just that we have absolutely no priority for it at the time)?
Yeah, okay, that's a good way to put it. Anyone who finds this issue, this close is "noone is able to work on this right now, and we don't see when we'll get to it", so if you would like this, please comment and we'll reopen.