A46: xDS NACK Semantics Improvement#260
Conversation
ejona86
left a comment
There was a problem hiding this comment.
Beautiful. That was well documented.
dfawley
left a comment
There was a problem hiding this comment.
A++++++++++++++++++ would read again.
|
Should a NACK sent in this situation indicate which resources are rejected vs accepted in a machine-readable way (i.e. other than in the error message)? |
There's no way to do that today. That's what I was referring to in the doc by saying that there will be some future work to change the xDS protocol to make that possible. |
srini100
left a comment
There was a problem hiding this comment.
Looks great! Thanks for taking care of this.
| supports the `RING_HASH` policy, then it cannot safely send a Cluster | ||
| resource configuring that policy, because that change would cause older | ||
| clients to stop functioning. | ||
|
|
There was a problem hiding this comment.
won't this be addressed by minor version support on server side?
There was a problem hiding this comment.
We still don't actually have a design for version negotiation, so that's not a solution for the immediate problem. And even once we do have such a design, I suspect that that's not going to be the best way to address this kind of use-case, because it would require the control plane to have a bunch of logic to determine how to configure older clients that don't support the current configuration.
I think having the control plane generate different versions of the config will make sense for cases where we are deprecating one set of fields and replacing them with another set, where the semantic meaning of the underlying config can be expressed equally well via both sets of fields. But I think it will be too complex to do in cases where the client simply does not support the features that the configuration is intending to configure, because I don't think the control plane can really know what to do in that case.
Implementing [gRFC A46](grpc/proposal#260)
Implementing [gRFC A46](grpc/proposal#260)
Implementing [gRFC A46](grpc/proposal#260)
No description provided.