John Howard

https://github.com/envoyproxy/envoy/issues/32823 is still imo and improvement envoy should make but we worked around it. Having trouble finding our workaround on my phone but basically we never send "removed" for ecds

> Well, in the case he's trying to fix, traffic disruption already is unavoidable and it shouldn't be unsafe: > > > In this case "Because init containers can be...

> Another thing we could do is say that there are no traffic disruption guarantees for init containers, because as per kube init containers can be restarted. > > And...

Nice, the new check sounds like it could be a lot more reliable. One thing I worry about is the init container case in Kubernetes. Its important to consider in...

> This is something we can exercise with unit tests. Any false-positive would be an istio-iptables expected state computation bug. Especially for non-upgrade scenarios (sidecars/init containers) - if the actual...

We only want to accept the tradeoff when istio-init spuriously restarts not if it failed previously. For any other case I think we need a "no tradeoffs" solution... I don't...

@bleggett my concern is our contract is "We will initialize iptables at pod startup". We do this through CNI or init-containers. Kubernetes has a ~bug (maybe they don't call it...

@kyessenov was looking into something similar I think

3 things are wrong: 1. should be `destination_principal="spiffe://cluster.local/ns/default/sa/default"` 2. The unknown values should not be unknown. maybe I didn't have `version` label, but i am sure I have `app` 3....

Mesh is blocked by https://github.com/kubernetes-sigs/gateway-api/pull/2873 Ingress can be made 'stable' IMO and use v1