John Howard

Its in your filter. `"!has(response.code) || response.code >= 500"` would probably be what you want; there is no `response.code` attribute at all on the failures

This is a super subtle and easy mistake to make, if you have any feedback on what changes could have made that solveable (docs, etc), please let us know

I believe it's a quirk of the logging vs filtering that it will plug in default values for unset fields. Really tricky to get right though, so needs some more...

`tags_.push_back({context_.destination_service_namespace_, context_.namespace_` and `tags_.push_back({context_.destination_workload_namespace_, context_.namespace_});` So our code makes the assumption service namespace == workload namespace. Instead we should get the service namespace from the clsuter metadata (which is already...

cc @kyessenov @zirain looks like an easy fix if my assumption is correct that we should change it to the cluster metadata

For workload namespace that makes sense, but Service_namespace is a service property not a workload one so seems appropriate to use the service metadata?

more https://prow.istio.io/view/gs/istio-prow/logs/integ-k8s-126_istio_postsubmit/1763304825484742656

i think it's different, that one didn't have istiod crashlooping. but maybe same

So the istiod is restarting many times. Its not failign with this on the initial install. So probably its crashing. And then fails to come up -- two separate bugs.

I think I get it. We have 2 files, but we do not read them atomically. I can reproduce by flipping between two cacerts. https://ahmet.im/blog/kubernetes-inotify/ touches on this but doesn't...