It would be nice if you substantiate this by giving a usecase. The command can be something like a setreplicaprop as a collection API. Yeah , it should be written by the overseer and it should be an overseer command. (I'm not endorsing the idea, just an implementation suggestion)
On Mon, Sep 8, 2014 at 10:24 PM, Erick Erickson <erickerick...@gmail.com> wrote: > I'm just not getting it. But then again it's late and the code is > unfamiliar.... > > Anyway, I'm working on SOLR-6491 for which I want to have a > preferredLeader property in ZK. > > I _think_ this fits best as a property in the same place as the > "leader" prop and it would be a boolean. I.e. the cluster state for > collection1/shards/shard1/replicas/core_node_2 might have a > "preferred_leader" attribute that could be set to "true". This would > be totally independent of whether or not "leader" was true, although > they would very often be the same. The "preferredLeader" is really > just supposed to be a hint at leader-election time. > > Anyway, all this seems well and good but I don't see a convenient way > to set/clear a single property in a single node in clusterstate. What > I think I'm seeing is that the cluster state is only written by the > Overseer and the Overseer doesn't deal with this case yet. Things like > updateState seem like they have another purpose. > > So I'm guessing that I need to write another command for Overseer to > implement, something like setnodeprop that takes a collection, shard, > node, and one or more (property/propval) pairs. Then, to change the > clusterstate I'd put together a ZkNodeProps and put it in the queue > returned from Overseer.getInQueue(zkClient). Then wait for it to be > processed before declaring victory (actually I'd only have to wait in > the test I think). > > Mostly I'm looking for whether this is on the right track or > completely of base. Also giving folks a chance to object before I > invest the time and effort in something totally useless. > > Thanks! > Erick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- ----------------------------------------------------- Noble Paul
