[
https://issues.apache.org/jira/browse/SOLR-16507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703343#comment-17703343
]
David Smiley commented on SOLR-16507:
-------------------------------------
Thanks AB! Do you think there's a point to SplitShardCmd using
NodeStateProvider vs just going to the metrics API? Basically, what value-add
is NSP offering? Maybe some limited caching but for splits that's not very
useful. If SSC using metrics API makes sense; it's probably warrants a
dedicated work item apart from this one.
I get your point that *something* has to gather node attributes, and probably
cache them. But NSP and its collaborators are needlessly complex! If we don't
tackle that complexity directly here, maybe we can at least make some
simplifications. Even just moving some separate classes (like Snitch etc.) to
be inner classes of NSP would be an improvement. At least the complexity would
be more contained / bundled.
> Remove NodeStateProvider & Snitch
> ---------------------------------
>
> Key: SOLR-16507
> URL: https://issues.apache.org/jira/browse/SOLR-16507
> Project: Solr
> Issue Type: Task
> Reporter: David Smiley
> Priority: Major
> Labels: newdev
>
> The NodeStateProvider is a relic relating to the old autoscaling framework
> that was removed in Solr 9. The only remaining usage of it is for
> SplitShardCmd to check the disk space. For this, it could use the metrics
> api.
> I think we'll observe that Snitch and other classes in
> org.apache.solr.common.cloud.rule can be removed as well, as it's related to
> NodeStateProvider.
> Only
> org.apache.solr.cluster.placement.impl.AttributeFetcherImpl#getMetricSnitchTag
> and org.apache.solr.cluster.placement.impl.NodeMetricImpl refer to some
> constants in the code to be removed. Those constants could move out,
> consolidated somewhere we think is appropriate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
