[jira] [Updated] (SOLR-6512) Add a collections API call to add/delete arbitrary properties to a specific replica

["Erick Erickson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erick Erickson updated SOLR-6512:
---------------------------------
    Summary: Add a collections API call to add/delete arbitrary properties to a specific replica  (was: Add a collections API call to add/delete arbitrary roles to a specific replica)

> Add a collections API call to add/delete arbitrary properties to a specific replica
> -----------------------------------------------------------------------------------
>
>                 Key: SOLR-6512
>                 URL: https://issues.apache.org/jira/browse/SOLR-6512
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>         Attachments: SOLR-6512.patch, SOLR-6512.patch
>
>
> This is a sub-task for SOLR-6491, but seems generally useful. 
> Since this is in support of the "preferredLeader" functionality, I've run into some considerations that I wanted some feedback on how to handle.
> "preferredLeader" has the restriction that there should only be one per slice, so setting this for a particular node means removing the property for all the other replicas on the slice. Not a problem to do, my question is more whether this is something reasonable to enforce on an arbitrary property based on what that property is? Perfectly do-able, but "semantically challenged". Currently, this is never a node with "preferedLeader" set to "false", it is forcibly removed from other nodes in the slice when this property is assigned.
> The problem here is that there's nothing about assigning an arbitrary property to a node that would reasonably imply this kind of behavior. One could always control this with secondary flags on the command, e.g. "shardExclusive=true|false" for instance, perhaps with safety checks in for known one-per-shard properties like "preferredLeader".
> "preferredLeader" seems to fit more naturally into a "role", but currently ADDROLE and DELTEROLE have nothing to do with the notion of setting a role for a particular node relative to a collection/shard. Easy enough to add, but enforcing the "only one node per slice may have this role" rule there is similarly arbitrary and overloads the ADDROLE/DELETEROLE in a way that seems equally confusing. Plus, checking whether the required collection/shard/node params are present becomes based on the value of the property being set, which is all equally arbitrary.
> The other interesting thing is that setting an arbitrary property on a node would allow one to mess things up royally by, say, changing properties like "core", or "base_url" or node_name at will. Actually this is potentially useful, but very, very dangerous and I'm not particularly interested in supporting it ;).  I suppose we could require a prefix, say the only settable properties are "property.whatever".
> We could also add something specific to nodes, something like ADDREPLICAROLE/DELETEREPLICAROLE, perhaps with sub-params like "onlyOneAllowedPerShard", but this gets messy and relies on the users "doing the right thing". I prefer enforcing rules like this  based on the role I think. Or at least enforcing these kinds of requirements on the "preferredLeader" role if we go that way.
> What are people's thoughts here? I think I'm tending towards the ADDREPLICAROLE/DELETEREPLICAROLE way of doing this, but it's not set in stone. I have code locally for arbitrary properties that I can modify for the role bits.
> So, if I'm going to summarize the points I'd like feedback on:
> 1> Is setting arbitrary properties on a node desirable? If so, should we require a prefix like "property" to prevent resetting values SolrCloud depends on?
> 2> Is it better to piggyback on ADDROLE/DELETEROLE? Personally I'm not in favor of this one. Too messy with requiring additional parameters to work right in this case
> 3> Is the best option to create new collections API calls for ADDREPLICAROLE/DELETEREPLICAROLE that
> 3.1> require collection/slice/node parameters
> 3.2> enforces the "onlyOnePerShard" rule for certain known roles
> 3.3 v1> allows users to specify arbitrary roles something like "onlyOnePerShard" as an optional T|F parameter, otherwise is totally open.
> -or-
> 3.3 v2> No support other than "preferredLeader", only roles that are pre-defined are allowed, in which case the "onlyOnePerShard" is implicit in the role.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org