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
Let us say we have 5 EDS clusters registered with Envoy. When an Endpoint for a particular cluster (cluster_1) changed, if a management server sends EDS update with resource list as (cluster_1), Envoy updates it stats correctly but it also increments update_empty stat for rest of the clusters.
It is because it fires an empty config update at this line https://github.com/envoyproxy/envoy/blob/master/source/common/config/grpc_mux_impl.cc#L218
Is this intentional behaviour? If it is intentional, I think it is pretty confusing to update other clusters stats indicating that empty update has come where as the intention of management server is not that.
The text was updated successfully, but these errors were encountered:
@ramaraochavali yeah, this behavior is a bit confusing. GrpcMuxImpl treats both CDS and EDS the same, where CDS subscribes with a single watch and EDS with many watches, one per cluster. You want this empty behavior for CDS but not EDS.
I'd consider this a bug, are you interested in taking a look at fixing? It should only be fixed for RDS/EDS, LDS/CDS should maintain their existing behaviors (there really are two classes of xDS effectively).
Fixes incorrect increment of update_empty stat for EDS when resource list contain does contain a particular cluster
Risk Level: Low
Testing: Automated tests
Docs Changes: N/A
Release Notes: N/A
Fixes#4241
Signed-off-by: Rama <rama.rao@salesforce.com>
Let us say we have 5 EDS clusters registered with Envoy. When an Endpoint for a particular cluster (cluster_1) changed, if a management server sends EDS update with resource list as (cluster_1), Envoy updates it stats correctly but it also increments
update_empty
stat for rest of the clusters.It is because it fires an empty config update at this line
https://github.com/envoyproxy/envoy/blob/master/source/common/config/grpc_mux_impl.cc#L218
Is this intentional behaviour? If it is intentional, I think it is pretty confusing to update other clusters stats indicating that empty update has come where as the intention of management server is not that.
The text was updated successfully, but these errors were encountered: