Ben Leggett

@biswajit-9776 Behavior should be the same in a mixed environment for every kind of workload as it would be if "only sidecar" workloads were deployed, or "only ambient" workloads were...

@biswajit-9776 The unit test you added there is redundant with an existing unit test (thanks for jumping in tho!) if you are interested in helping here, could you look at...

@pglushko asked for it - if they are still working on it, maybe check with them. More detail on the integration tests and what I'm specifically talking about: `istio-cni` is...

As mentioned in the PR: I do think disabling repair for the `ambient` integ tests is better - we should not need `repair` in that suite, and if we do...

Yep, maybe `integration/ambient/repair_test.go` which installs with repair ON and makes sure nothing breaks. We can have either - repair default-OFF for the entire ambient test suite, and one test that...

> Should this be part of the same PR or a different one? Ideally same, I guess? But I am ok with either.

Thinking about it, I guess this is not practically fixable except by adopting https://github.com/istio/istio/pull/48818 / https://github.com/istio/istio/pull/49092 to entirely obviate the need for crash-based race repair.

Now that the untaint controller is in I would actually advocate we drop this form of race repair _entirely_, and point people to `istio-cni` + the untaint controller instead. Need...

Yes, this is the same problem as: https://github.com/istio/istio/issues/47436#issuecomment-1769526105 `plugin type="loopback" failed (delete): missing network name` this seems to be a problem with `docker desktop`'s cluster setup specifically, they are shipping...

@MorrisLaw probably yes. I can't test this as there's no Docker Desktop build for my arch/platform. It's not ambient-specific however, as `plugin type="loopback" failed (delete): missing network name` would manifest...