[ https://issues.apache.org/jira/browse/SOLR-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155106#comment-14155106 ]
ASF subversion and git services commented on SOLR-6512: ------------------------------------------------------- Commit 1628773 from [~erickoerickson] in branch 'dev/trunk' [ https://svn.apache.org/r1628773 ] SOLR-6512: Add a collections API call to add/delete arbitrary properties 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, 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