[WIP] remove streamState from SOTW cache #577
Conversation
| } | ||
| } | ||
|
|
||
| if previousResourceNames, ok := resourceNames[req.TypeUrl]; ok && !stringSlicesEqual(previousResourceNames, req.ResourceNames) { |
There was a problem hiding this comment.
If the user is only unsubscribing to a resource there is no need to push back all other resources iiuc
So stringSlicesEqual could be more stringSlicesIncluded
There was a problem hiding this comment.
Maybe, though if you look at istio's implementation - they resend response on every resourcenames change even if the list actually become smaller.
| resourceNames []string | ||
| } | ||
|
|
||
| func stringSlicesEqual(s1, s2 []string) bool { |
There was a problem hiding this comment.
Does it mean we will send again all resources if the order is changing?
If the client is in go (thinking grpc for instance) this is likely to occur and ideally we should not push again
There was a problem hiding this comment.
in this case - yes, in future - it may be changed to be sets/maps. this PR as of now is just an intention.
|
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
…interface is breaking the separation of concern between the server side managing the xds protocol itself and the cache which is only in charge of returning responses based on watches PR envoyproxy#577 has been opened proposing to fully remove any client state from the CreateWatch interface This commit is updating the Cache interface based on a few concerns/aspects: - one of the argument on removing it is that the sotw protocol is stateless. It actually is not, and is explicitly visible in this PR: the lastResponse latched value as well as the version hack when the resource list is changed very well show that it is stateful - in cases outside of lds and cds, it is clearly stated that the control-plane is not expected to send back all resources when a single one change. This is highly critical in the case of ads with eds, as there is a likelihood of both having a lot of resources and a high churn. The implementation sending everything each time is technically tolerated, but is pushing on the data-plane work that could be done at low cost on the control-plane - the current support of both delta and sotw, for both linear and simple cache means that every change has to be done 4 times, with four very different implementations, each one supporting only a subset of use cases (e.g. linear does not support cds/lds as it doesn't handle wildcard in this case, and sotw does not work properly as resource list is improperly maintained). I strongly believed that both implementation should converge. The only remaining differences should be in the messages themselves, abstracted in the server part. Having a common interface for sotw and delta is a first step for this. It would also allow in the future to make snapshot far more efficient by supporting a linear version per snapshot In this context, this commit is changing: - creates a SubscriptionState within the cache package, driven by the data needed from the cache perspective to be able to answer a client request - simplifies streamState - makes it compatible with the new SubscriptionState interface - removes the IsFirst notion, as the protocol states it should come from the nonce in the request - removes the duplicate/parallel knownResourceNames and use the delta one instead. It will also properly carry the version in a future PR Signed-off-by: Valerian Roche <valerian.roche@datadoghq.com>
No description provided.