-
Notifications
You must be signed in to change notification settings - Fork 94
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
gRPC configuration management control plane API #10
Comments
Came up in Slack - we may want to do two builds of Quilkin. One that allows the YAML file, and one that only allows gPRC. Because the client side proxy essentially can't be trusted. To be explored more. |
Further references on Envoy xDS: https://github.com/envoyproxy/go-control-plane |
Takeaways I had from xDS api chat with had with Googler/xDS friends:
How does that sound to anyone? |
* Add xds proto code generation Work on #10
This adds the logic to processes responses from the XDS server and sends back acknowlegements according to the protocol. Implementation to talk to the server isn't included. Work on #10
This adds the logic to processes responses from the XDS server and sends back acknowlegements according to the protocol. Implementation to talk to the server isn't included. Work on #10
* Add XDS logic for cluster and endpoints This adds the logic to processes responses from the XDS server and sends back acknowlegements according to the protocol. Implementation to talk to the server isn't included. Work on #10 * include xds modules when running doctest * exclude xds cluster in rustdoc, refactor
Adds an abstraction that knows about the different types of clusters/endpoints sources - handling both from static configuration file or XDS configuration Work on #10
Adds an abstraction that knows about the different types of clusters/endpoints sources - handling both from static configuration file or XDS configuration Work on #10
Adds an abstraction that knows about the different types of clusters/endpoints sources - handling both from static configuration file or XDS configuration Work on #10
* Add a ClusterManager abstraction Adds an abstraction that knows about the different types of clusters/endpoints sources - handling both from static configuration file or XDS configuration Work on #10 Co-authored-by: Mark Mandel <markmandel@google.com>
Integrates the XDS client into the cluster manager Work on #10
An endpoint will have associated metadata - provided by the XDS API that can contain e.g tokens for that endpoint. Work on #10
This includes the endpoint metadata provided by the XDS API as a JSON object internally. Work on #10
* Add dynamic proxy configuration Integrates the XDS client into the cluster manager * Do not store endpoints per cluster * update clone depth * update proxy config Work on #10
This includes the endpoint metadata provided by the XDS API as a JSON object internally. Work on #10
This includes the endpoint metadata provided by the XDS API as a JSON object internally. Work on #10 Co-authored-by: Mark Mandel <markmandel@google.com>
Parses generic yaml key values into a json value and in order to use as the endpoint's metadata. Values under the `quilkin.dev` key is reserved for quilkin usage. Extracts token into the endpoint object since we don't want to traverse the json value on each lookup. Removes name and connection ID from the static Endpoint config struct. Work on #10 Fixes #152
Parses generic yaml key values into a json value and in order to use as the endpoint's metadata. Values under the `quilkin.dev` key is reserved for quilkin usage. Extracts token into the endpoint object since we don't want to traverse the json value on each lookup. Removes name and connection ID from the static Endpoint config struct. Work on #10 Fixes #152
Rather than retry. Also pass a struct with all resource handlers to the client rather than individually. This allows us to easily add the listener handler later. Work on #10
* Endpoint metadata support from static config Parses generic yaml key values into a json value and in order to use as the endpoint's metadata. Values under the `quilkin.dev` key is reserved for quilkin usage. Extracts token into the endpoint object since we don't want to traverse the json value on each lookup. Removes name and connection ID from the static Endpoint config struct. Work on #10 Fixes #152 * Rename token key
* xds fail fast on invalid URI Rather than retry. Also pass a struct with all resource handlers to the client rather than individually. This allows us to easily add the listener handler later. Work on #10
Adds filter manager logic to listen for LDS resources and construct filter chains from them. This required moving some common setup out of the current CDS listener. Does not update the proxy to use the filter chain from the filter manager - follow up PR will do this. Work on #10
Adds filter manager logic to listen for LDS resources and construct filter chains from them. This required moving some common setup out of the current CDS listener. Does not update the proxy to use the filter chain from the filter manager - follow up PR will do this. Work on #10
* Add XDS Filter implementation Adds filter manager logic to listen for LDS resources and construct filter chains from them. This required moving some common setup out of the current CDS listener. Does not update the proxy to use the filter chain from the filter manager - follow up PR will do this. Work on #10 Co-authored-by: Mark Mandel <markmandel@google.com>
Enables the filter manager which can either be static or dynamic depending on config, in place of the static filter chain. Also remove the `filters` field from `dynamic` section of static configs since we can now fetch those from the XDS server. Work on #10
* Enable XDS filter manager Enables the filter manager which can either be static or dynamic depending on config, in place of the static filter chain. Also remove the `filters` field from `dynamic` section of static configs since we can now fetch those from the XDS server. Work on #10 Co-authored-by: Mark Mandel <markmandel@google.com>
* Add proto config for all filters work on #10 * use proto3
* Add xDS integration test Work on #10 * fix compilation Co-authored-by: Mark Mandel <markmandel@google.com>
This should be able to be closed now, yes? |
Yes! |
(Placeholder for further discussion).
We'll need some kind of API surface for dynamic configuration values. Most likely to provide the capabilities for people to create their own control planes.
The way Envoy does it is quite well tested, and we can likely lift many ideas from it.
https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol
(Not the only API Envoy has, may also be worth looking at the whole thing: https://www.envoyproxy.io/docs/envoy/latest/api/api)
The text was updated successfully, but these errors were encountered: