Ryan Drew

Looking through the connectivity test source, it should be expected to see drops for any HTTP path other than "/". The l7 policy from the sysdump shows that only "/"...

Looks like we use `cilium policy wait` to wait for policy revisions in the connectivity test, but when the envoy config has been updated, we increment a separate "proxy policy...

I think that would make sense. I'm going to do some more digging through the sysdumps to double check if this would help and then get started on an implementation.

I looked back through the sysdumps and I think it makes to give the proxy policy revision waiting a shot. I've been brainstorming a solution and the trick part is...

If we want to roll these up together, we'd have to be a bit careful to make sure we don't break any existing assumptions (ie adding a policy bumps the...

I don't know where to go from here. We could try bumping the timeout value in the curl command, but I don't know if that would help. I've been looking...

Looks like this might be related, but the test doesn't deploy envoy as a Daemonset: https://github.com/cilium/cilium/issues/28057

Looking through how the `Endpoint.waitForProxyCompletions` function works, it seems that it may not return exactly after the envoy proxy is hot reset. I figured a simple solution we could try...

Removing myself as assignee for ci-health tophat handoff

> I think I was wrong about this, although the policy version doesn't increment until endpoint regenerate the cilium-cli also uses cilium policy wait for all endpoints to stabilize before...