Since the problem described in this issue should be resolved in a recent advisory, it has been closed.

For information on the advisory (Moderate: Red Hat OpenShift Service Mesh Containers for 2.6.0 security update), and where to find the updated files, follow the link below.

If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2024:5094

yes gmonahan, that is a good place for this information. Maybe add there also info that the other timeout must be higher then query_timeout:

` The default `query_timeout` is 30. If you set it higher than 30, you need to update `.spec.server.write_timeout` in Kiali CR and add the annotation `haproxy.router.openshift.io/timeout=50s` to the Kiali route. Note that `.spec.server.write_timeout` and `haproxy.router.openshift.io/timeout=` must be higher then `query_timeout`

OK. The "Type" is "Bug" so wanted to check.

It might make more sense to add a callout to `query_timeout`https://docs.openshift.com/container-platform/4.15/service_mesh/v2x/ossm-observability.html#ossm-configuring-distr-tracing-tempo_observability  so users see it.

Something like this:

apiVersion: kiali.io/v1alpha1
kind: Kiali

1. ...
   spec:
     external_services:
       tracing:
         query_timeout: 30 <1> 
         enabled: true
         in_cluster_url: 'http://tempo-sample-query-frontend.tracing-system.svc.cluster.local:16685'
         url: '[Tempo query frontend Route url]'
         use_grpc: true <2>

<1> The default `query_timeout` is 30. If you set it higher than 30, you need to update `.spec.server.write_timeout` and add the annotation `haproxy.router.openshift.io/timeout=50s` to the Kiali route.
<2>If you are not using the default HTTP or gRPC port for Jaeger or Tempo, replace the `in_cluster_url:` port with your custom port

I think it would be more accurate to considered this issue as an improvement more than a bug as this is a workaround for when the Tracing service is very slow, there is not really any bugfix in Kiali. What do you think, mkralik@redhat.com?

Hey mkralik@redhat.com ,

Is this a bug to be included in 2.6 Rel Notes? If so, the "Release Notes Text" field must follow the bug description template: "Previously, <X problem> caused <Y situation>  Now, <fix> resolves the issue  <agent> can <perform operation> successfully."

Thanks!

This is related to this warning:

As there is already a warning here, we could add a note to indicate that it could be also possible to increase the server time out.

rhn-engineering-jshaughn sounds good about updating the description in kiali.io. This specific page is updated with a Kiali operator update? I've updated the operator description: https://github.com/kiali/kiali-operator/pull/794 (For what I understand, this is copied for the kiali.io release bot)

So...does this need to be added to 2.6 Rel Notes as a "Bug fix" or as a "Kiali known issue"? I do agree with Jay that it will get lost in Rel Notes, esp with the way 2.x Rel Notes are structured.

Also, does the Note for the updated OSSM 2.6 Tempo instructions in this PR, https://github.com/openshift/openshift-docs/pull/77583 , need to be updated? The Kiali Note is line 149.

Or is this just being documented upstream?

rh-ee-jcordoba , I'm not opposed to adding a Jira release note for this issue.  But relnotes can get lost and are for a targeted audience.  I think it might be nice to add an openshift-specific note here, about the route annotation:

https://kiali.io/docs/configuration/kialis.kiali.io/#.spec.server.write_timeout

That way anyone setting that config would know to also update the route.

rhn-engineering-jshaughn as this is in OpenShift, maybe it can be included in the Red Hat Kiali documentation as a note?

Thanks mkralik@redhat.com , that seems like really important information.  We should document this,  rh-ee-jcordoba , where do you think we should put this information?