[
https://issues.apache.org/jira/browse/SOLR-16507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703746#comment-17703746
]
Andrzej Bialecki commented on SOLR-16507:
-----------------------------------------
bq. Do you think there's a point to SplitShardCmd using NodeStateProvider vs
just going to the metrics API?
You're making my point for me ;) you could do that, but the SplitShardCmd would
become very complex with a lot of non-reusable code - because you would still
have to bake-in making HTTP requests to other nodes and parsing / extracting
metrics values. So it's better to hide this complexity in a high-level utility
API.
IMHO NodeStateProvider is a good abstraction, just its implementation needs to
be cleaned up.
> 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: [email protected]
For additional commands, e-mail: [email protected]