Skip to content

delta-xds: avoid sending resource names for wildcard requests on stream reconnect#16153

Merged
yanavlasov merged 6 commits intoenvoyproxy:mainfrom
adisuissa:delta_xds_reconnect_resources
Apr 28, 2021
Merged

delta-xds: avoid sending resource names for wildcard requests on stream reconnect#16153
yanavlasov merged 6 commits intoenvoyproxy:mainfrom
adisuissa:delta_xds_reconnect_resources

Conversation

@adisuissa
Copy link
Copy Markdown
Contributor

Commit Message: delta-xds: avoid sending resource names for wildcard requests on stream reconnect

Additional Description:
Avoiding sending resource names for wildcard requests after the stream is dropped.
The resources are sent in initial_resource_versions, but the new request must have no resources in resource_names_subscribe so the server will understand this is a wildcard request.

Risk Level: Medium? breaks current behavior, which is incorrect.
Testing: Added unit and integration tests.
Docs Changes: Updated xds docs.
Release Notes: N/A.
Platform Specific Features: N/A.
Fixes #16063

Signed-off-by: Adi Suissa-Peleg [email protected]

Signed-off-by: Adi Suissa-Peleg <[email protected]>
grpc_mux_->onDiscoveryResponse(std::move(response), control_plane_stats_);
}
// Send another response with a different resource, but where EDS is paused.
auto resume_cds = grpc_mux_->pause(type_url);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why did you add an update with a paused mux to this test?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This is done to emulate a disconnect before an ack is sent from the client, and ensure that the message on reconnect does include the new resource.
I'll add some comments to this test.

@dmitri-d
Copy link
Copy Markdown
Contributor

lgtm, other than a small question re: test.

@adisuissa
Copy link
Copy Markdown
Contributor Author

/assign @stevenzzzz

stevenzzzz
stevenzzzz previously approved these changes Apr 26, 2021
Copy link
Copy Markdown
Contributor

@stevenzzzz stevenzzzz left a comment

Choose a reason for hiding this comment

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

LGTM

:ref:`initial_resource_versions <envoy_api_field_DeltaDiscoveryRequest.initial_resource_versions>`.
Because no state is assumed to be preserved from the previous stream, the reconnecting
client must provide the server with all resource names it is interested in. Note that for wildcard
requests (e.g., CDS/LDS), the request must have no resources in both
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

srds is wildcard as well.

@adisuissa
Copy link
Copy Markdown
Contributor Author

/assign @htuch

@yanavlasov yanavlasov merged commit d86bd11 into envoyproxy:main Apr 28, 2021
gokulnair pushed a commit to gokulnair/envoy that referenced this pull request May 6, 2021
…am reconnect (envoyproxy#16153)

Signed-off-by: Adi Suissa-Peleg <[email protected]>
Signed-off-by: Gokul Nair <[email protected]>
gokulnair pushed a commit to gokulnair/envoy that referenced this pull request May 6, 2021
…am reconnect (envoyproxy#16153)

Signed-off-by: Adi Suissa-Peleg <[email protected]>
Signed-off-by: Gokul Nair <[email protected]>
rboyer added a commit to hashicorp/consul that referenced this pull request Jan 25, 2022
When a wildcard xDS type (LDS/CDS/SRDS) reconnects from a delta xDS stream,
prior to envoy `1.19.0` it would populate the `ResourceNamesSubscribe` field
with the full list of currently subscribed items, instead of simply omitting it
to infer that it wanted everything (which is what wildcard mode means).

This upstream issue was filed in envoyproxy/envoy#16063 and fixed in
envoyproxy/envoy#16153 which went out in Envoy `1.19.0` and is fixed in later
versions (later refactored in envoyproxy/envoy#16855).

This PR conditionally forces LDS/CDS to be wildcard-only even when the
connected Envoy requests a non-wildcard subscription, but only does so on
versions prior to `1.19.0`, as we should not need to do this on later versions.

This fixes the failure case as described here: #11833 (comment)

Co-authored-by: Huan Wang <[email protected]>
hc-github-team-consul-core pushed a commit to hashicorp/consul that referenced this pull request Jan 25, 2022
When a wildcard xDS type (LDS/CDS/SRDS) reconnects from a delta xDS stream,
prior to envoy `1.19.0` it would populate the `ResourceNamesSubscribe` field
with the full list of currently subscribed items, instead of simply omitting it
to infer that it wanted everything (which is what wildcard mode means).

This upstream issue was filed in envoyproxy/envoy#16063 and fixed in
envoyproxy/envoy#16153 which went out in Envoy `1.19.0` and is fixed in later
versions (later refactored in envoyproxy/envoy#16855).

This PR conditionally forces LDS/CDS to be wildcard-only even when the
connected Envoy requests a non-wildcard subscription, but only does so on
versions prior to `1.19.0`, as we should not need to do this on later versions.

This fixes the failure case as described here: #11833 (comment)

Co-authored-by: Huan Wang <[email protected]>
rboyer added a commit to hashicorp/consul that referenced this pull request Jan 25, 2022
When a wildcard xDS type (LDS/CDS/SRDS) reconnects from a delta xDS stream,
prior to envoy `1.19.0` it would populate the `ResourceNamesSubscribe` field
with the full list of currently subscribed items, instead of simply omitting it
to infer that it wanted everything (which is what wildcard mode means).

This upstream issue was filed in envoyproxy/envoy#16063 and fixed in
envoyproxy/envoy#16153 which went out in Envoy `1.19.0` and is fixed in later
versions (later refactored in envoyproxy/envoy#16855).

This PR conditionally forces LDS/CDS to be wildcard-only even when the
connected Envoy requests a non-wildcard subscription, but only does so on
versions prior to `1.19.0`, as we should not need to do this on later versions.

This fixes the failure case as described here: #11833 (comment)

Co-authored-by: Huan Wang <[email protected]>
rboyer added a commit to hashicorp/consul that referenced this pull request Jan 25, 2022
When a wildcard xDS type (LDS/CDS/SRDS) reconnects from a delta xDS stream,
prior to envoy `1.19.0` it would populate the `ResourceNamesSubscribe` field
with the full list of currently subscribed items, instead of simply omitting it
to infer that it wanted everything (which is what wildcard mode means).

This upstream issue was filed in envoyproxy/envoy#16063 and fixed in
envoyproxy/envoy#16153 which went out in Envoy `1.19.0` and is fixed in later
versions (later refactored in envoyproxy/envoy#16855).

This PR conditionally forces LDS/CDS to be wildcard-only even when the
connected Envoy requests a non-wildcard subscription, but only does so on
versions prior to `1.19.0`, as we should not need to do this on later versions.

This fixes the failure case as described here: #11833 (comment)

Co-authored-by: Huan Wang <[email protected]>

Co-authored-by: Huan Wang <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[delta-xds] do not populate resource_names_subscribe with existing resources on reconnection for "wildcard" XDSes

6 participants