Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[sotw][issue-540] Return full state when applicable for watches in linear cache #856

Closed

Conversation

valerian-roche
Copy link
Contributor

This PR is currently based on #854, and include its diff too, but in a separate commit

Fixes #540

This PR is fixing issue #540: the xds protocol defines that for the resource types Listener and Cluster, when using sotw watches, the cache must return as part of the response all existing resources matching the requests if not wildcard.
Currently the control-plane will only return the modified resources on cache updates, and the protocol states that the client should interpret such a response as a deletion

In simple cache this distinction is not applicable as we currently always return all resources. While we may want to improve this behavior in the future (e.g. to avoid sending all clusters if only one was updated in delta, or to send a single route configuration in sotw on update), this is out of scope of this PR as this requires keeping more state

…ches subscribing to multiple resources

Properly return the request in sotw responses to allow proper handling in callbacks

Signed-off-by: Valerian Roche <[email protected]>
@@ -327,8 +341,12 @@ func (cache *LinearCache) CreateWatch(request *Request, _ stream.StreamState, va
case err != nil:
stale = true
staleResources = request.GetResourceNames()
cache.log.Debugf("Watch is stale as version failed to parse %s", err.Error())

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: add a colon to separate error from the string: Watch is stale as version failed to parse: %s

Also I see some log lines are prefixed with [linear cache], you may want to add that here and at L348, too.

Comment on lines 105 to 106
// for some types. This is relied on by xds-grpc which is explicitly requesting clusters but expect
// to receive all existing resources
Copy link

@atollena atollena Jan 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a way, yes, this is a specificity of xDS gRPC, because xDS gRPC uses resource names with LDS and CDS, whereas IIUC, envoy does not and instead uses wildcards. For cases where Envoy does (ODCDS?) then I don't know how resource deletions are handled.

I would add here that for gRPC clients, not including a resource in LDS or CDS indicates that the resource has been deleted, as described at https://www.envoyproxy.io/docs/envoy/v1.28.0/api-docs/xds_protocol#deleting-resources.

Co-authored-by: Antoine Tollenaere <[email protected]>
Signed-off-by: Valerian Roche <[email protected]>
@valerian-roche valerian-roche deleted the vr/resource-returned branch January 17, 2024 03:14
@valerian-roche valerian-roche restored the vr/resource-returned branch January 17, 2024 03:14
Copy link

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!

@github-actions github-actions bot added the stale label Feb 16, 2024
Copy link

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!

@github-actions github-actions bot closed this Feb 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

In LinearCache, respond can't tell the caller is from update or delete.
2 participants