Chen Youxiong

> That proposal seems to put it in Virtual service? Yes, it's still in VirutalService. Actually we have similar requirement in Contour and what we did was adding the default_cluster...

> As mentioned in [#38105 (comment)](https://github.com/istio/istio/issues/38105#issuecomment-1095651333), I don't believe VirtualService is the right place for this. @howardjohn What about DestinationRule? There is already failover mechanism in DestinationRule but just for...

There is `failoverPriority` in DestinationRule but currently it's an ordered list not the priority level but it's quite similar. And those proposals require api change. Another thought is that we...

@howardjohn is it acceptable to add this failover cluster in DestinationRule? Either with a DR annotation like `traffic.istio.io/failover` or change the DestinationRule to support to failover to default cluster?

Log of another igw pod, the sequence is: 1. istiod receieved full CDS push request due to istiod somehow restarted, envoy started a full CDS push request and istiod pushed...

> Possibly fixed by #39937 Seems not, the fix https://github.com/istio/istio/pull/39960 is already in istio 1.17 but clusters still got stuck.

> I missed `ADS:EDS: FORCE RESPONSE` - This means Istiod is actually responding with EDS. Will have to look deeper on why Envoy is still not warming - Step 4...

From the log, I see the xds_proxy downstream push stuck [here](https://github.com/istio/istio/blob/master/pkg/istio-agent/xds_proxy.go#L590-L593C3) with error `downstream [%d] dropped xds push to Envoy, connection already closed`, so `sendDownstream` never got chance to trigger....

Change istio-proxy log level requires ingressgw recreate right, then most likely we can't reproduce.

The issue was gone and not able to reproduce now, but let me share more logs when this issue happened. The issue happened when there was an upstream error `xdsproxy...