Define in_cluster_url for tracing on non standard 80 port

This probably has nothing to do with it, but in Kiali 2.x, in_cluster_url is deprecated in lieu of internal_url.

• https://kiali.io/news/release-notes/#200
• change names of url / in_cluster_url to better reflect what they are #7745

The version check was changed recently though - perhaps some problem was introduced here?

• grafana and tracing versions should be obtained over in_cluster_url #7758

Define in_cluster_url for tracing on non standard 80 port

This probably has nothing to do with it, but in Kiali 2.x, in_cluster_url is deprecated in lieu of internal_url.

Yes, my fault - we're utilizing internal_url of course.

The code causing this is likely here: https://github.com/kiali/kiali/blob/v2.4.0/status/versions.go#L98-L112
In case of gRPC the port is stripped off the URL, but there is no way to determine the HTTP port and ports 80/443 are statically used.
... https://github.com/kiali/kiali/blob/v2.4.0/status/versions.go#L103

This may be a duplicate of #8106.

I think the status API call should not block the login screen, so I've created a PR for this: #8131

Regarding why the check url is not working when Jaeger is not deployed in the standard port (80): This happens when gRPC is used, as gRPC doesn't have an endpoint that returns the version, to avoid an additional configuration url, Kiali tries to obtain the URL from the http endpoint, and Kiali uses the same url as gRPC, but using the standard port (@jmazzitelli , I think that was the decision about this: #7746 (comment)). Probably this should be changed.

as gRPC doesn't have an endpoint that returns the version

If this is true, and our attempt to retrieve it from the HTTP endpoint doesn't work because the port cannot be auto-detected, then we need a way to tell Kiali to not even bother to do the version check.

So I would say we can do one of two things:

1. If gRPC is configured, rip out that code I added to try to go over HTTP over standard port - just don't check it at all (i.e. if "gRPC is enabled, disable the version check entirely")
2. Have a configuration option for the user to tell us to not perform the version check. This allows us to keep that code to fallback to the HTTP endpoint - so if the user does have the HTTP endpoint bound to the standard port, the version check will work. But if the user is using gRPC without the HTTP endpoint point to the standard port, this allows them to tell Kiali to not do the check at all.

So the options are (1) implicitly disable the check if gRPC is enabled and (2) allow the user to explicitly disable the check if gRPC is enabled and they don't have an HTTP endpoint on the standard port.

I'm OK with doing either one. I'll leave it up to the person who chooses to implement this fix.

as gRPC doesn't have an endpoint that returns the version

If this is true, and our attempt to retrieve it from the HTTP endpoint doesn't work because the port cannot be auto-detected, then we need a way to tell Kiali to not even bother to do the version check.

So I would say we can do one of two things:

1. If gRPC is configured, rip out that code I added to try to go over HTTP over standard port - just don't check it at all (i.e. if "gRPC is enabled, disable the version check entirely")

2. Have a configuration option for the user to tell us to not perform the version check. This allows us to keep that code to fallback to the HTTP endpoint - so if the user does have the HTTP endpoint bound to the standard port, the version check will work. But if the user is using gRPC without the HTTP endpoint point to the standard port, this allows them to tell Kiali to not do the check at all.

So the options are (1) implicitly disable the check if gRPC is enabled and (2) allow the user to explicitly disable the check if gRPC is enabled and they don't have an HTTP endpoint on the standard port.

I'm OK with doing either one. I'll leave it up to the person who chooses to implement this fix.

I think we could go for 2) so at least it is possible to get the version in certain conditions. I can included in the PR #8131

I'm also OK with either option, @josunect can decide which route to take. For option 2, we could make it opt-in, so the version check does not happen by default.

Is login the only slow-down point? I thought users were seeing slow-down across the UI.

I'm also OK with either option, @josunect can decide which route to take. For option 2, we could make it opt-in, so the version check does not happen by default.

Is login the only slow-down point? I thought users were seeing slow-down across the UI.

I've seen the status call taking a lot of time. In my dev env, takes more than 3 seconds where the others take some ms.
At the moment I don't think other calls are creating a bottleneck here.