[
https://issues.apache.org/jira/browse/SOLR-18004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18041670#comment-18041670
]
Jan Høydahl commented on SOLR-18004:
------------------------------------
It's not necessarily hard to send CORS headers from solr. And in a cluster
where Admin UI is loaded directly from a Solr server, i.e. using same URLs as
the backend itself, it is not hard either to send the correct allow header
automatically. What may muddy the waters are cases where:
# Admin UI may be served through a reverse proxy (e.g. k8s ingress) on a
different url, e.g. [https://solr01.foo.com/admin/] may point to backend
[http://host01.bar.com:8983/solr/#/]
# The reverse proxy (e.g. a k8s ingress) may use paths instead of host names
to address individual solr nodes [https://ingress.foo.com/solr/node01/],
[https://ingress.foo.com/solr/node02/]
# The environment may not have exposed every single Solr node outside the
cluster, i.e. [https://solr.foo.com/admin/] may be the only URL available,
which may load balance to any random Solr node, in which case it is impossible
to achieve the functionality.
If we delagated to the frontend to contact each Solr node to fetch metrics (and
also admin/info/system, admin/zookeeper and admin/collections), we'd need two
more pieces of mandatory configuration for Solr:
* A {{SOLR_CORS}} configuration, where you must list each possible
scheme://host:port allowed
* A way to tell the Admin UI how to translate the list of host names it gets
from {{live_nodes}} into actual user-facing URLs.. This could be a map
({{{}[http://host01.bar.com:8983|http://host01.bar.com:8983/] ->
[https://solr01.foo.com/admin/]{}}}) or a regex rule
({{{}[http://host(\d+)\.bar\.com:8983|http://host(d+).bar.com:8983/] ->
[https://ingress.foo.com/solr/node$1]{}}}) for cases where it's not a 1:1
mapping.
But for case 3 above we'd be up against the wall and the UI would not work at
all. And I fear that case 3 is not that uncommon. They may even have several
layers of reverse proxying before we reach the end user, and there may be
Authentication enabled on the Gateway/Ingress level, setting a cookie in the
browser, so that once the UI attempts a fetch() outside of the domain, the
cookie will not be sent and the Gateway/ingress will redirect for new
authentication. This can even be an issue with Solr's own Auth or MTLS setup.
Thus I took the safe way out and stuck with the same approach we know works.
> Admin UI nodes view throws "unsupported format requested: json"
> ---------------------------------------------------------------
>
> Key: SOLR-18004
> URL: https://issues.apache.org/jira/browse/SOLR-18004
> Project: Solr
> Issue Type: Sub-task
> Components: Admin UI, metrics
> Affects Versions: 10.0
> Reporter: Matthew Biscocho
> Priority: Blocker
> Labels: pull-request-available
> Fix For: 10.0
>
> Attachments: Screenshot 2025-11-28 at 12.33.41 PM.png
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The admin UI cloud -> nodes view is throwing an error "Only Prometheus and
> OpenMetrics metric formats supported. Unsupported format requested: json".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
