envoyproxy / envoy

Cloud-native high-performance edge/middle/service proxy
https://www.envoyproxy.io
Apache License 2.0
24.28k stars 4.69k forks source link

xds: dynamic context params for new-style names #14428

Open markdroth opened 3 years ago

markdroth commented 3 years ago

This builds on the new xDS naming scheme described in #11264.

We have a need for the control plane to be able to provide some dynamic context parameters to be used when requesting LDS, RDS, CDS, EDS, et al resource names.

This doc describes the use-cases and proposes a mechanism to provide this functionality:

https://docs.google.com/document/d/1GO6HJ08wbMqLEjVGit5AxMiEAdHzZnT84f4A9Xg5Jp0/edit

Update: The above doc has been superseded by https://github.com/cncf/xds/blob/main/proposals/TP2-dynamically-generated-cacheable-xds-resources.md.

CC @htuch

htuch commented 3 years ago

One thing I'd add is that clients, specifically Envoy in some use cases we need, will also have internal dynamic context parameters. These will be sourced from binary-local sources, e.g. some OOB node-local config source.

htuch commented 3 years ago

Another consideration (doc isn't world commentable) is around consistency. Since xDS is eventually consistent, it's actually pretty tricky for a DCP server to determine when the new context parameters are in effect if needed. I'm not sure if that's something we need to solve in or out-of-band, but worth calling out explicitly.

markdroth commented 3 years ago

I've fixed the permissions on the doc. Sorry about that!

markdroth commented 3 years ago

With regard to consistency, I think the DCP server can tell whether the new context params are in effect by seeing whether the client has updated all of its subscriptions.

mattklein123 commented 3 years ago

At a high level this makes sense to me, though I left one comment in the doc about potential xDS ordering issues that we probably need to be pretty explicit about. We can discuss in the doc or here.

tonya11en commented 1 month ago

/assign tonya11en