[ 
https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438537#comment-16438537
 ] 

Jan Høydahl edited comment on SOLR-8207 at 4/14/18 11:14 PM:
-------------------------------------------------------------

For the new "Nodes" view, I am whipping up a patch and currently draw the whole 
table from the {{CLUSTERSTATUS}} info. But when trying to pull system/metrics 
info from other nodes we of course bump into CORS issues. There are two ways to 
work around this:
 * Add CORS support to Solr's Jetty, automatically allowing all host names in a 
cluster
 * Add some {{/api/proxy}} endpoint that will proxy requests from the UI to 
other nodes. Example:
{code:java}
/api/proxy?node=192.168.0.3:8983_solr&endpoint=/api/node/system&params=foo{code}

I think the proxy approach is preferable since it will then also work if you 
only have access to one Solr node in a cluster, or you access Admin UI through 
ssh forwarding, where real host/IPs don't resolve from the client network. 
There are challenges with the proxy approach as well, as it needs to strictly 
allow only requests to whitelisted nodes that exist in ZK. It also needs to 
handle authentication, simplest is to always use PKI when talking to other 
nodes. Authorization must perhaps validate its permission rules relative to the 
resolved endpoint in addition to the /proxy/ one so this does not become a 
loophole to allow any action once authenticated. And finally, the handler 
should have config to lock down proxying to certain methods (only GET by 
default) and to certain endpoints.


was (Author: janhoy):
For the new "Nodes" view, I am whipping up a patch and currently draw the whole 
table from the {{CLUSTERSTATUS}} info. But when trying to pull system/metrics 
info from other nodes we of course bump into CORS issues. There are two ways to 
work around this:
 * Add CORS support to Solr's Jetty, automatically allowing all host names in a 
cluster
 * Add some {{/api/proxy}} endpoint that will proxy requests from the UI to 
other nodes. Example: 
{code}/api/proxy?node=192.168.0.3:8983_solr&endpoint=/api/node/system&params=foo{code}

I think the proxy approach is preferable since it will then also work if you 
only have access to one Solr node in a cluster, or you access Admin UI through 
ssh forwarding, where real host/IPs don't resolve from the client network. 
There are challenges with the proxy approach as well, as it needs to strictly 
allow only requests to whitelisted nodes that exist in ZK. It also needs to 
handle authentication, simplest is to always use PKI when talking to other 
nodes. And finally, the handler should have config to lock down proxying to 
certain methods (only GET by default) and endpoints.

> Modernise cloud tab on Admin UI
> -------------------------------
>
>                 Key: SOLR-8207
>                 URL: https://issues.apache.org/jira/browse/SOLR-8207
>             Project: Solr
>          Issue Type: Improvement
>          Components: Admin UI
>    Affects Versions: 5.3
>            Reporter: Upayavira
>            Assignee: Jan Høydahl
>            Priority: Major
>         Attachments: nodes-tab.png
>
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 
> the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to