[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
