Ben Leggett

> We have an order defined,so it's just the ordering is t ideal (?) I see what appears to be an order for `install`: https://github.com/istio/istio/blob/d86983c25c52002ca3db9ff8e444340dcd7956cf/operator/pkg/object/objects.go#L421 ...it's not the same as...

https://github.com/istio/istio/pull/52541#discussion_r1714470816 is A Reason (specific to test code) why following the Helm order doesn't work for us specifically - leader election lock timeouts.

> Hi @bleggett,Thanks for reviewing,could you please help me with the function whose addition of a testcase(unit testcase) won't be a trivial one or a way to find such functions...

+1 on having some abstraction here that makes it easier to detangle `istio CA` from the rest of istiod, since absolutely nothing about how that CA works should be istio-specific,...

If we require people to build and ship a custom sidecar to use a non-default CA, then I feel like that's a signal we are too tightly coupled to our...

> Then there is Istiod's serving certificate. This is very intentionally not coupled to workload mTLS, specifically to avoid tight coupling to Istio CA. This is why when we connect...

If we are concerned about `PILOT_CERT_PROVIDER` having too many options, I would actually suggest we should drop our own `file` impl from the list and add something like SDS, and...

> > The point is, istiod really shouldn't care, as long as a valid cert gets pushed to it. > > I 100% agree with this, Istiod should not be...

I'll try to get a doc together for a WG to look at the options/problems and lay them out.

https://docs.google.com/document/d/1diXyh76FMgUTh6Rr79dyJXTMamtsfXwvMtfvT95mX0M/edit?usp=sharing Doc here in the Istio GDoc share which lays out (I believe) the options going forward here - I'm not bringing it up for discussion at today's WG since...