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

Ishan Chattopadhyaya commented on SOLR-15694:
---------------------------------------------

[~janhoy], thanks. That is good feedback.

bq. This has been discussed many times.
Can you please point me to that? Will link to that in future discussions.

bq.  I think it should be a generic concept of a "node role", which can then be 
one or more roles that will dictate how the node acts.
Today, we have a role "overseer" for a node. However, many users look for 
dedicated overseer nodes (nodes that don't handle querying or indexing), and 
there's no easy way today. 

bq. and then you could combine it with "data" if the node should also be 
eligible for index/search.
Do you recommend that we have a role "data" for nodes (regular nodes as we have 
today)? In that case, what would absence of this "data" role for a node mean 
the node doesn't host any cores? This seems reasonable for what I intend to 
achieve with usecases I have in mind.

bq. This is definitely SIP worthy.
I'll create one, thanks :-)

> Concept of non-data nodes
> -------------------------
>
>                 Key: SOLR-15694
>                 URL: https://issues.apache.org/jira/browse/SOLR-15694
>             Project: Solr
>          Issue Type: New Feature
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: AutoScaling
>            Reporter: Ishan Chattopadhyaya
>            Priority: Major
>
> 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.3.4#803005)

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

Reply via email to