Skip to content
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

Pluggable Gateway #861

Open
danehans opened this issue Mar 14, 2025 · 4 comments
Open

Pluggable Gateway #861

danehans opened this issue Mar 14, 2025 · 4 comments

Comments

@danehans
Copy link

danehans commented Mar 14, 2025

🚀 Feature Description and Motivation

I am a kgateway maintainer. In the upcoming release, kgateway will support Kubernetes Gateway API Inference Extension. The aibrix Gateway overlaps with Gateway API Inference Extension, specifically the endpoint picker extension. Can the aibrix Gateway component become extensible in the architecture? A spec, conformance tests, etc. can be defined to support aibrix Gateway extensibility. By doing so, aibrix will benefit from wider adoption.

Use Case

As a kgateway user with Gateway API inference Extension, I prefer to integrate with Aibrix instead of having separate Gateways.

Proposed Solution

Develop an interface, spec, conformance tests, etc. to make the aibrix extensible and allow integration with Gateway API inference extension conformant implementations.

@kfswain
Copy link

kfswain commented Mar 14, 2025

Agreed here! We worked closely with aibrix contributors before and would love to continue that trend!

@Jeffwan @varungup90 I've looked for an aibrix community meeting in your docs and couldnt find one. Would be happy to pop in to to discuss what gaps we think need to be covered for GIE to be more composable with aibrix. If that sounds good, I can get a doc drafted on the topic.

Thanks! Looking forward to it!

@linsun
Copy link

linsun commented Mar 14, 2025

+1 as an Istio and kgateway maintainer, I would like our users stay with whatever gateways they feel comfortable.

@kerthcet
Copy link
Collaborator

I followed the design of GIE in early days, and asked one question like If inference platform has their own model object, will there a conceptual conflict exists?, because according to the design, GIE has its own inferenceModel and inferencePool, but seems no answer. Nowadays, we met the question in our inference platform so we may consider to employ the envoy gateway ourself just because we don't want to have too much model-like objects to our users, which is confusing, and aibrix may introduce the same API as well, see #299.

TBH, we don't want to reimplement the wheel. Not represent the aibrix community, but our platform.

@varungup90
Copy link
Collaborator

For AIBrix, our goal is to not restrict users to use specific component or module and be as much extensible. We should schedule a meeting to discuss more on this topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants