Open markdroth opened 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.
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.
I've fixed the permissions on the doc. Sorry about that!
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.
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.
/assign tonya11en
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