[mesh page] per-control-plane istio settings

[nrfox]

What do you want to improve?

There's a number of istio settings that Kiali exposes like mTLS for the namespace/cluster/mesh. These need to take into account multiple controlplanes whether that's single cluster when multiple revisions are present or multi-cluster with a multi-primary deployment.

What is the current behavior?

Multiple controlplanes are not used when reporting istio settings.

What is the new behavior?

All relevant controlplanes are used when reporting istio settings.

[jshaughn]

Note that the new mesh page will start with the current assumptions but will need to integrate this enhancement. I'm going to incorporate into the mesh page epic, but not for the initial release milestone.

[jshaughn]

I think this is really "Determine correct Istio versions for multi-primary scenarios" as I'm not aware of what other Istio settings we're talking about in the description, or not already handled by the new mesh page.

[nrfox]

I'd say it's bigger than that. It's many of the settings under external_services.istio like config_map_name. Some of these settings are used in various places like validations:

kiali/business/istio_validations.go

Line 407 in 976461b

istioDomain := strings.Replace(config.Get().ExternalServices.Istio.IstioIdentityDomain, "svc.", "", 1)

and probably would lead to incorrect results if they differ between primaries and/or revisions.

Never mind this issue is specifically for the mesh page. So it would be things like the mtls lock icons which only take into account a single configmap from a single revision:

kiali/business/tls.go

Lines 192 to 195 in 976461b

	istioConfig, err := kubeCache.GetConfigMap(cfg.IstioNamespace, IstioConfigMapName(*cfg, ""))
	if err != nil {
	return true
	}

.

[jshaughn]

Thanks for the clarification, @nrfox. It sounds almost like this should be an epic, with different information being handled as individual issues. I had currently been treating this one as a follow-up for istio version.