[
https://issues.apache.org/jira/browse/SOLR-15694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17863527#comment-17863527
]
Aparna Suresh commented on SOLR-15694:
--------------------------------------
Hi [~ichattopadhyaya],
We are trying to use the _Node roles_ feature to set a preferred Overseer in
our Solr 9 fork. What is the purpose of having _overseerDesignate_ in addition
to specifying a {_}preferredOverseer{_}? How is it specified via startup
parameters?
In our fork, I am configuring one node in the SolrCloud cluster with
{{{}-Dsolr.node.roles=overseer:preferred,data:on{}}}. All other nodes are set
to {{overseer:allowed,data:on}} by default. I have observed that during a
rolling restart, the _OverseerNodePrioritizer_ almost always elects the
preferred Overseer as the Overseer, provided it is up. Additionally, since the
overseerDesignate list remains empty (until the preferred Overseer is added to
it), it does not affect this outcome.
> Concept of node roles and non-data nodes
> ----------------------------------------
>
> Key: SOLR-15694
> URL: https://issues.apache.org/jira/browse/SOLR-15694
> Project: Solr
> Issue Type: New Feature
> Components: AutoScaling
> Reporter: Ishan Chattopadhyaya
> Priority: Major
> Fix For: 9.0
>
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> I think we should have first class support for starting a Solr node in a mode
> whereby no cores will be placed on them. These nodes are useful for certain
> scenarios:
> # Dedicated overseer nodes
> # Nodes where only plugins are installed and used (e.g. cluster/node level
> plugins)
> # Dedicated nodes for querying (more on this to come later).
> Today, to achieve this effect, one can:
> 1. start a node (which will make it join live_nodes and be immediately
> available for replica placement).
> 2. Put replica placement rules or autoscaling policies to prevent replicas
> from being placed there. This is not standardized, 8x has two ways to achieve
> this (replica placement rules and autoscaling framework), 9x has a new
> autoscaling framework.
> Proposing a start parameter for starting a node that starts the node in this
> configuration, and then internally this is handled appropriately (across 8x
> and 9x). This should be Kubernetes/Docker friendly as well, since it is easy
> to add an additional parameter for a startup (instead of putting things into
> autoscaling.json in ZK via init scripts).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
