You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: site-src/faq.md
+9-12Lines changed: 9 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,26 +5,23 @@ The [contributing](/contributing) page keeps track of how to get involved with
5
5
the project.
6
6
7
7
## Why isn't this project in the main Gateway API repo?
8
-
This project is an extension of Gateway API, and may eventually be merged into
9
-
the main Gateway API repo. As we're starting, this project represents a close
10
-
collaboration between
8
+
This project builds on top of Gateway API, however, the Gateway API [repo](https://github.com/kubernetes-sigs/gateway-api) is, as the name implies, an API definition, and does not contain deployables. Inference Gateway deviates from this; with the EPP & BBR deployables, and projects (like [llm-d](https://github.com/llm-d)) depending on these binaries, merging this into the Gateway API repo would deviate from how that repo operates.
9
+
10
+
Additionally, this project represents a close collaboration between
and the [Gateway API](https://gateway-api.sigs.k8s.io/) subproject. These groups
14
14
are all well represented within the ownership of this project, and the separate
15
15
repo enables this group to iterate more quickly as this project is getting
16
-
started. As the project stabilizes, we'll revisit if it should become part of
17
-
the main Gateway API project.
16
+
started.
18
17
19
18
## Will there be a default controller implementation?
20
19
No. Although this project will provide a default/reference implementation of an
21
20
extension, each individual Gateway controller can support this pattern. The
22
21
scope of this project is to define the API extension model, a reference
23
-
extension, conformance tests, and overall documentation.
22
+
extension, conformance tests, and overall documentation.
23
+
24
+
A default controller for CRDs that do not have a Gateway dependency may be considered in the future.
24
25
25
-
## Can you add support for my use case to the reference extension?
26
-
Maybe. We're trying to keep the scope of the reference extension fairly narrow
27
-
and instead hoping to see an ecosystem of compatible extensions developed in
28
-
this space. Unless a use case fits neatly into the existing scope of our
29
-
reference extension, it would likely be better to develop a separate extension
30
-
focused on your use case.
26
+
## Can you add support for my use case?
27
+
Definitely. We are always happy to accept proposals to improving inference capabilities! However, the extensible and pluggable architecture of the EPP can allow for you to add it yourself, benchmark the capabilities, and then share those with the community. If you are looking for a place for more experimental features, [llm-d](https://github.com/llm-d) is a great place for incubation, many ideas and optimizations that start there, graduate to this repo. Additionally, many of us that work on this project, work there as well!
0 commit comments