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

gRPC configuration management control plane API #10

Closed
markmandel opened this issue Jan 28, 2020 · 6 comments
Closed

gRPC configuration management control plane API #10

markmandel opened this issue Jan 28, 2020 · 6 comments
Labels
area/operations Installation, updating, metrics etc area/user-experience Pertaining to developers trying to use Quilkin, e.g. cli interface, configuration, etc kind/design Proposal discussing new features / fixes and how they should be implemented kind/feature New feature or request

Comments

@markmandel
Copy link
Member

(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)

@markmandel markmandel added kind/feature New feature or request area/operations Installation, updating, metrics etc area/user-experience Pertaining to developers trying to use Quilkin, e.g. cli interface, configuration, etc kind/design Proposal discussing new features / fixes and how they should be implemented labels Jan 28, 2020
@markmandel
Copy link
Member Author

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.

@markmandel
Copy link
Member Author

markmandel commented Jul 29, 2020

@luna-duclos
Copy link
Collaborator

luna-duclos commented Jul 29, 2020

@markmandel
Copy link
Member Author

markmandel commented Aug 12, 2020

Takeaways I had from xDS api chat with had with Googler/xDS friends:

  • The current xDS implementation could likely work for much of our use case, but we would likely ignore most of it for our use case
  • Let's do research to work out what the smallest sliver of xDS we would need to use to support our configuration model
    • Sounds like we could maybe start with just filters and clusters+locality+endpoints?
  • Come up with a back-of-napkin design of how integration with Agones/Open Match might look like, just to verify the model
  • Biggest question I still have is how we represent our auth token routing in an xDS world.

How does that sound to anyone?

iffyio added a commit that referenced this issue Sep 17, 2020
iffyio added a commit that referenced this issue Oct 14, 2020
* Add xds proto code generation

Work on #10
iffyio added a commit that referenced this issue Oct 14, 2020
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
iffyio added a commit that referenced this issue Oct 14, 2020
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
markmandel pushed a commit that referenced this issue Oct 22, 2020
* 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
iffyio added a commit that referenced this issue Nov 7, 2020
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
iffyio added a commit that referenced this issue Nov 7, 2020
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
iffyio added a commit that referenced this issue Nov 7, 2020
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
markmandel added a commit that referenced this issue Nov 18, 2020
* 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>
iffyio added a commit that referenced this issue Dec 3, 2020
Integrates the XDS client into the cluster manager

Work on #10
iffyio added a commit that referenced this issue Dec 5, 2020
An endpoint will have associated metadata - provided by the XDS API
that can contain e.g tokens for that endpoint.

Work on #10
iffyio added a commit that referenced this issue Dec 5, 2020
This includes the endpoint metadata provided by the XDS API as a JSON
object internally.

Work on #10
markmandel pushed a commit that referenced this issue Dec 7, 2020
* 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
iffyio added a commit that referenced this issue Dec 8, 2020
This includes the endpoint metadata provided by the XDS API as a JSON
object internally.

Work on #10
markmandel added a commit that referenced this issue Dec 11, 2020
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>
iffyio added a commit that referenced this issue Dec 14, 2020
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
iffyio added a commit that referenced this issue Dec 14, 2020
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
iffyio added a commit that referenced this issue Dec 14, 2020
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
markmandel pushed a commit that referenced this issue Jan 13, 2021
* 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
iffyio added a commit that referenced this issue Jan 14, 2021
* 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
iffyio added a commit that referenced this issue Jan 21, 2021
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
iffyio added a commit that referenced this issue Jan 22, 2021
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
markmandel added a commit that referenced this issue Feb 5, 2021
* 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>
iffyio added a commit that referenced this issue Feb 11, 2021
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
iffyio added a commit that referenced this issue Feb 13, 2021
* 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>
iffyio added a commit that referenced this issue Feb 15, 2021
iffyio added a commit that referenced this issue Feb 15, 2021
iffyio added a commit that referenced this issue Feb 15, 2021
iffyio added a commit that referenced this issue Feb 20, 2021
* Add proto config for all filters

work on #10

* use proto3
iffyio added a commit that referenced this issue Mar 10, 2021
iffyio added a commit that referenced this issue Mar 14, 2021
* Add xDS integration test

Work on #10

* fix compilation

Co-authored-by: Mark Mandel <markmandel@google.com>
@markmandel
Copy link
Member Author

This should be able to be closed now, yes?

@iffyio
Copy link
Collaborator

iffyio commented May 6, 2021

Yes!

@iffyio iffyio closed this as completed May 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/operations Installation, updating, metrics etc area/user-experience Pertaining to developers trying to use Quilkin, e.g. cli interface, configuration, etc kind/design Proposal discussing new features / fixes and how they should be implemented kind/feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants