[
https://issues.apache.org/jira/browse/SOLR-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15336355#comment-15336355
]
Jan Høydahl edited comment on SOLR-9194 at 6/17/16 7:55 PM:
------------------------------------------------------------
I'm actually not a fan of "there being many ways to do the same thing", think
Perl....
-1 for combining the prefix notation with anything having to do with synonyms.
And I _do_ like the zk: prefix, Jan's quiz is a good one. Plus (see below)
there's no reason the copy command can't have both the src and dst be znodes.
I'll treat file: as a default, people will be able to specify it for
consistency, but it'll be the assumed prefix for anything without zk:. And at
least one zk: prefix _will_ be required.
With synonyms and the zk: prefix, these are equivalent and I'm not going to
even try to write the help text for explaining that.
put zk:path_on_zk path_on_local
put path_on_local zk:path_on_zk
put file:path_on_local zk:path_on_zk
As I was working on this yesterday I realized the cp command is not necessarily
local<\->zk only, it's perfectly possible to do a zk<\->zk copy. My question is
whether it would be _useful_. Because I'm also not a fan of burdening code with
useless functionality. Any opinions here on whether zk<\->zk copy is desirable?
I admit I'm having trouble thinking of reasons why you'd want to do this. It
seems to me that the usual use-case is to copy from ZK, change then copy back
up to ZK in a different place. And the zk<\->zk copy can be accomplished in two
steps.
I suppose it's "perfectly possible" to have the bin/solr script do a
local<\->local copy but that's just silly ;)...
And one final question: ZkConfigManager already has all the recursive copy code
for going back and forth between ZK and local uploadToZK/downloadFromZK.
Currently they're private. I'm not about to cut/paste so the question becomes
whether these should just be made public or extracted to some utility?
was (Author: erickerickson):
I'm actually not a fan of "there being many ways to do the same thing", think
Perl....
-1 for combining the prefix notation with anything having to do with synonyms.
And I _do_ like the zk: prefix, Jan's quiz is a good one. Plus (see below)
there's no reason the copy command can't have both the src and dst be znodes.
I'll treat file: as a default, people will be able to specify it for
consistency, but it'll be the assumed prefix for anything without zk:. And at
least one zk: prefix _will_ be required.
With synonyms and the zk: prefix, these are equivalent and I'm not going to
even try to write the help text for explaining that.
put zk:path_on_zk path_on_local
put path_on_local zk:path_on_zk
put file:path_on_local zk:path_on_zk
As I was working on this yesterday I realized the cp command is not necessarily
local<->zk only, it's perfectly possible to do a zk<->zk copy. My question is
whether it would be _useful_. Because I'm also not a fan of burdening code with
useless functionality. Any opinions here on whether zk<->zk copy is desirable?
I admit I'm having trouble thinking of reasons why you'd want to do this. It
seems to me that the usual use-case is to copy from ZK, change then copy back
up to ZK in a different place. And the zk<->zk copy can be accomplished in two
steps.
I suppose it's "perfectly possible" to have the bin/solr script do a
local<->local copy but that's just silly ;)...
And one final question: ZkConfigManager already has all the recursive copy code
for going back and forth between ZK and local uploadToZK/downloadFromZK.
Currently they're private. I'm not about to cut/paste so the question becomes
whether these should just be made public or extracted to some utility?
> Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper
> ----------------------------------------------------------------------------
>
> Key: SOLR-9194
> URL: https://issues.apache.org/jira/browse/SOLR-9194
> Project: Solr
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Minor
>
> There are a few other files that can reasonably be pushed to Zookeeper, e.g.
> solr.xml, security.json, clusterprops.json. Who knows? Even
> <collection>/state.json for the brave.
> This could reduce further the need for bouncing out to zkcli.
> Assigning to myself just so I don't lose track, but I would _love_ it if
> someone else wanted to take it...
> I'm thinking the commands would be
> bin/solr zk -putfile -z <ensemble> -p <zookeeper path> -f <local file path>
> bin/solr zk -getfile -z <ensemble> -p <zookeeper path> -f <local file path>
> but I'm not wedded to those, all suggestions welcome.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
