Suppor for relative path using QUERY_BASE_PATH

[Sidhartha-Biswal]

Hi,

Does QUERY_BASE_PATH environment variable support relative-path case while using reverse proxy? Can it be set using QUERY_STATIC_FILES?

What are the possible values for QUERY_STATIC_FILES environment variable?

[yurishkuro]

Static files flag is a legacy remnant from the time when ui assets were packaged separately from the binary and you could point the binary to different locations for those. Since the assets are bundled inside the binary now this flag is not needed.

[yurishkuro]

It didn't work for me either when public and internal prefix was different, why don't you make it the same?

[Sidhartha-Biswal]

Hi @yurishkuro,

We want public and internal prefix to be different. Does Jaeger support that?

We set the query_base_path as "/hub/jaeger-query/v1/jaeger/viewer" and then modified the virtual service configuration as mentioned below. But it did not work. Please suggest your opinion about what could be the issue.

match:
uri:
prefix: /hub/jaeger-query/v1/jaeger/viewer
rewrite:
uri: /hub/jaeger-query/v1/jaeger/viewer
retries:
attempts: 3
perTryTimeout: 15s
retryOn: connect-failure,refused-stream,reset,unavailable,cancelled,resource-exhausted
route:
destination:
host: api-gateway
port:
number: 8080
timeout: 15s

[yurishkuro]

Different public/private prefixes do not work today (it would require configuring them separately in jaeger-query, which is not supported). Theoretically you can make it work by doing rewriting, but it's pretty tricky to do for an AJAX app which constructs URLs on the fly from Javascript.

[Sidhartha-Biswal]

Hi @yurishkuro,
We would like to know if this is a bug in Jaeger and will this use case be supported if any modifications are done in the Jaeger source code or if it is an issue with the client side configuration/code. Please share your opinion.

[yurishkuro]

Bug is subjective - I don't see it as a bug, Jaeger is doing what it promises to do, and it has no control over layers you put on top of it. Like I said, I think it's possible to support your use case by introducing two independent "prefixes", local (current implementation) and external (to be used from the UI). But not supporting it is not a bug, just a missing feature.

You may open a ticket to describe your use case and why it's important (and cannot be done using the existing support), and if there is interest in the community it may be implemented (I think changes are relatively simple).