xRFC TP2: Dynamically Generated Cacheable xDS Resources #10
Conversation
Signed-off-by: Mark D. Roth <roth@google.com>
|
@hzxuzhonghu @ramaraochavali should take a look as we have been looking into caching XDS in Istio. I haven't had a chance to take a look yet but planning to soon. |
|
What's tricky for istio is: we donot know which are the dynamic parameters for xds clients in advance, because users may have policies with workload selector. |
Signed-off-by: Mark D. Roth <roth@google.com>
Signed-off-by: Mark D. Roth <roth@google.com>
Signed-off-by: Mark D. Roth <roth@google.com>
|
I've removed the DPDS functionality from this xRFC, since I don't think it fully solves the problem of server-specified constraints: the DPDS resource itself would be uncacheable, which means that the client needs to talk to the authoritiative server anyway, but the whole point of dynamic parameters is to make resources cacheable. Therefore, DPDS seems no better than simply marking the resources that we wanted to dynamically generate as being non-cacheable. I do think this issue will probably need more attention later, but I think we can decouple that from the basic dynamic parameter design here. |
…ic params instead Signed-off-by: Mark D. Roth <roth@google.com>
…rces Signed-off-by: Mark D. Roth <roth@google.com>
Signed-off-by: Mark D. Roth <roth@google.com>
There was a problem hiding this comment.
I've done a major rewrite of this design, now focusing solely on the "dynamic route selection" use-case, which I think will be the overwhelmingly common case. The design has gone back to an earlier approach where the client sends dynamic parameters and the constraints are associated with the resources sent from the server. And I've simplified the constraints representation to handle the cases that I think we actually need.
@mattklein123 @htuch @fuqianggao @adisuissa @ejona86 Please review. Thanks!
Signed-off-by: Mark D. Roth <roth@google.com>
Signed-off-by: Mark D. Roth <roth@google.com>
There was a problem hiding this comment.
Overall proposal looks good, a bunch of tiny and bigger comments. Thanks for putting this together @markdroth!
/wait
Signed-off-by: Mark D. Roth <roth@google.com>
|
@markdroth sorry catching up from leave. Where are we at with this? Should I do another pass and then we can get this merged or are there other pending changes I should wait for? |
Signed-off-by: Mark D. Roth <roth@google.com>
Signed-off-by: Mark D. Roth <roth@google.com>
|
LGTM, will defer to @mattklein123 for final approval/merge. |
|
The main open issue that I think we still need to resolve here is where to land on the trade-off between flexibility of matching semantics vs. complexity of server and cache implementations, especially given how hard it will be to extend this later. I'd like to make sure we have consensus on that before merging this. |
There was a problem hiding this comment.
Sorry for the delay. In general this looks great. My general feeling though is we should plan for the expansion of matching capabilities. Personally, I like the idea of client capabilities, as that would allow us to not only handle additions, but also potentially features that certain implementations don't want to support (e.g., "crazy regex matching option").
Signed-off-by: Mark D. Roth <roth@google.com>
|
I've sent envoyproxy/envoy#20926 with the proto changes. |
| @@ -562,25 +515,15 @@ that a server has the following two variants of a resource: | |||
|
|
|||
There was a problem hiding this comment.
Are you saying that this type of configurations are not allowed based on the best practice?
There was a problem hiding this comment.
Yes. If the server always ensures that all variants of a resource have non-overlapping constraints for the same set of keys, then this kind of conflict cannot happen.
There was a problem hiding this comment.
OK. Can you make this a bit more clear?
There was a problem hiding this comment.
I think the existing wording here covers this:
This situation will be avoided via a best practice that all authoritative
xDS servers should have all variants of a given resource specify
non-overlapping constraints for the same set of keys.
Can you suggest what wording change(s) might make this clearer?
|
/lgtm |
CC @fuqianggao @adisuissa