[
https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401967#comment-16401967
]
Cassandra Targett commented on SOLR-8207:
-----------------------------------------
I'm glad you picked this up, Jan, I was looking at it earlier this morning
wishing I had time to work on it.
I'm mostly on board with your suggestions, but have a couple of thoughts:
* I think we should avoid renaming "Tree" to "ZooKeeper".
** There is a strong perception that in order to use Solr at all, you must
also learn ZK on Day One, which adds to the perception that Solr is difficult
to use and manage. To counteract this, we should in general move to considering
all the ZK-specific stuff as an implementation detail and present it to users
as such. Our guiding principle should be that users perceive their interactions
with the system as being primarily with Solr (via APIs, CLI, etc.) to the
extent that it's possible for us to make it appear that way, and Solr should
seamlessly handle whatever it needs to put/remove/etc into ZK to distribute it
around a cluster (there are obvious obstacles to this being reality 100% of the
time, but the way I've thought of it is you should only need to learn ZK once
you're well-versed in how everything else works, not just to create your first
collection or simply enable basic authentication). This isn't about hiding ZK
necessarily, it's about making Solr easier to learn and manage over time. This
principle is why we did the {{_default}} configset stuff, and why you can now
enable auth via {{bin/solr}} (there is for sure a lot more to do in this area).
** What would a better name be? All that said, I don't have a good suggestion
at the ready. If we think about what the Tree view is meant to do - provide
access to global and collection-level configurations - perhaps that suggests
alternatives..."Configs" springs to mind as an obvious choice, but feels weak.
I'm not sure if the position I stated is at all controversial, but perhaps
there are other ideas out there.
* The Nodes view has some interesting data on it as you've conceived of it,
and the status of each node is important information for sure. I think it would
be nice if it could show the names and states of the shards that are on each
node. Maybe that should be a secondary view for that screen? Something like,
click the # of shards and a list pops up? The graph view, which you've renamed
Collections (+1 IMO), would show where replicas are from the POV of each
collection, but if I'm looking at a node that's perhaps trending unhealthy, I'd
want to see from the node POV what's on each node.
> 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: Upayavira
> 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: [email protected]
For additional commands, e-mail: [email protected]
