Add an "Implementing a Compatible Data Plane" section to the implementers guide #1143
Conversation
k8s-ci-robot
added
the
cncf-cla: no
|
Welcome @AndresGuedez! |
|
Hi @AndresGuedez. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
k8s-ci-robot
added
needs-ok-to-test
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
/check-cla |
1 similar comment
|
/check-cla |
|
/ok-to-test |
k8s-ci-robot
added
ok-to-test
|
/easycla |
| - From extension to data plane: the metadata contains the selected endpoints. | ||
| - From data plane to extension: the metadata contains an optional subset of endpoints that the extension should pick from. |
There was a problem hiding this comment.
Unfortunately mkdocs list formatting is pretty unforgiving. Generally need an empty line before any list starts: https://deploy-preview-1143--gateway-api-inference-extension.netlify.app/guides/implementers/#implementing-a-compatible-data-plane. Same comment applies throughout, will likely take some trial and error.
| - From extension to data plane: the metadata contains the selected endpoints. | |
| - From data plane to extension: the metadata contains an optional subset of endpoints that the extension should pick from. | |
| - From extension to data plane: the metadata contains the selected endpoints. | |
| - From data plane to extension: the metadata contains an optional subset of endpoints that the extension should pick from. |
There was a problem hiding this comment.
Fixed this. The markdown preview I was using seemed fine with the formatting, but I'll rely on the generated site pages going forward to catch this.
site-src/guides/implementers.md
Outdated
|
|
||
| Supporting this broad range of extension capabilities (including for inference, as evidenced above) requires hooks into all HTTP stream (i.e., request and response) lifecycle events as well as the corresponding headers, trailers and payload. This is the core value proposition for ext_proc, along with configurable options (such as for buffering and streaming modes) that enable its use across a variety of deployment scenarios and networking topologies. | ||
|
|
||
| #### Native Implementations |
There was a problem hiding this comment.
| #### Native Implementations | |
| #### Open Source Implementations |
site-src/guides/implementers.md
Outdated
|
|
||
| #### Native Implementations | ||
|
|
||
| Several native implementations can be used as references: |
There was a problem hiding this comment.
| Several native implementations can be used as references: | |
| Several open source implementations can be used as references: |
site-src/guides/implementers.md
Outdated
| The key requirements for implementing the GIE protocol are as follows: | ||
| - Relies on the [ext_proc (External Processing)](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_proc_filter) protocol as the foundation for exchanging HTTP stream payload and metadata throughout the various HTTP lifecycle events; several key details: | ||
| - ext_proc relies on gRPC (bidirectional streaming) as the transport protocol | ||
| - ext_proc supports several processing modes, including buffered and streaming options for payload exchange |
There was a problem hiding this comment.
Should probably be mentioned that GIE only support FULL_DUPLEX_STREAMED now, full duplex uses specific proto objects so there isn't cross compatibility with the less strict options.
I think that could be changed upstream however.
There was a problem hiding this comment.
Discussed with Kellen offline -- the requirement for FULL_DUPLEX_STREAMED is not well specified right now. Let's deal with this in the EPP protocol proposal itself.
|
/approve Conceptually looks great! As Rob mentioned, mkdocs can be painful to work with, i reccomend using the link in the netlify comment Will leave Rob to give the LGTM stamp. Thanks Andres! |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: AndresGuedez, kfswain The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
k8s-ci-robot
added
cncf-cla: yes
|
Thanks @AndresGuedez! /lgtm |
k8s-ci-robot
added
the
lgtm
…ters guide (kubernetes-sigs#1143) * add an "Implementing a Compatible Data Plane" section to the implementers guide. * minor cleanup * update bullet list formatting. * minor cleanup.
This PR adds a section to the implementers guide with an outline for implementing compatible data planes that conform to the Endpoint Picker protocol.
/cc @robscott