John Howard
John Howard
This one is not using internal listener at all, this is just mainline Istio from `master`
What info do you need? I can consistently reproduce running Istio tests in CI and locally, but haven't gotten to a minimal Envoy-only config. Here are some debug logs [logs-1.txt](https://github.com/envoyproxy/envoy/files/9416993/logs-1.txt)...
This is still happening, not stale.
[logs1.txt](https://github.com/envoyproxy/envoy/files/9914220/logs1.txt) [logs2.txt](https://github.com/envoyproxy/envoy/files/9914221/logs2.txt) [logs3.txt](https://github.com/envoyproxy/envoy/files/9914222/logs3.txt) Here are 3 different instances. Let me know if you need something else
I am not quite sure I follow. Wouldn't that mean there is a loop? The request flow should just be `app -> outbound sidecar -> inbound sidecar -> other app`....
Yes, in `log1.txt` the app can be calling itself. So we have `app -> outbound envoy -> inbound envoy (the same envoy instance!) -> app (the same app!)`. For the...
`topologyKeys` is deprecated fwiw. replaced by https://kubernetes.io/docs/concepts/services-networking/topology-aware-hints/
``` $ uname -r 5.4.144+ ``` This one is probably partially my bad :-). But there will still be issues since it cannot even schedule the pod in current state
Ok on newer GKE version, now I just get: ``` [ -f bpf/mb_connect.c ] && make -C bpf load || make -C bpf load-from-obj make[1]: Entering directory '/app/bpf' clang -O2...
Seems clusterrole needs Watch permission on pods