You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
Envoy's support for the State-of-the-World and Delta-xDS gRPC muxes started as 2 different implementations.
There's been an effort (#17352) to converge the 2 code-bases into a single one - unified gRPC mux - that is currently under a runtime guard envoy_reloadable_features_unified_mux and defaults to false. Before converting the runtime flag to true, Envoy needs to ensure that doing so won't result in a breaking behavior.
Known differences will be tracked in this issue:
A request for a child resource will always be sent after receiving the parent resource in the non-unified SotW implementation.
Example: Say a cluster configured to use EDS is received using CDS. In the non-unified SotW implementation, Envoy will always send an EDS request for that resource, even when receiving an update to a known cluster. In the (nun-unified) delta-xDS implementation, and in the unified gRPC implementations (SotW and delta-xDS), Envoy will only send a request on the first request for the EDS resource.
A server may erroneously depend on receiving that request in order to send an update to the Envoy.
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
adisuissa
added
no stalebot
Disables stalebot from closing an issue
and removed
stale
stalebot believes this issue/PR has not been touched recently
labels
Aug 17, 2023
Converge to unified gRPC mux
Description:
Envoy's support for the State-of-the-World and Delta-xDS gRPC muxes started as 2 different implementations.
There's been an effort (#17352) to converge the 2 code-bases into a single one - unified gRPC mux - that is currently under a runtime guard envoy_reloadable_features_unified_mux and defaults to false. Before converting the runtime flag to true, Envoy needs to ensure that doing so won't result in a breaking behavior.
Known differences will be tracked in this issue:
Example: Say a cluster configured to use EDS is received using CDS. In the non-unified SotW implementation, Envoy will always send an EDS request for that resource, even when receiving an update to a known cluster. In the (nun-unified) delta-xDS implementation, and in the unified gRPC implementations (SotW and delta-xDS), Envoy will only send a request on the first request for the EDS resource.
A server may erroneously depend on receiving that request in order to send an update to the Envoy.
AIs:
The text was updated successfully, but these errors were encountered: