[
https://issues.apache.org/jira/browse/SOLR-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-9194:
---------------------------------
Attachment: SOLR-9194.patch
Here's a pretty complete patch for the Unix side, I'd appreciate anyone who
wants to give it a whirl and provide feedback. There are several things I'd
like people to look at if they have an opinion:
> First checking if my Git mojo is improved enough to create a complete patch
> when adding new files.....
> I added a configsets/cloud-subdirs directory so I'd have something concise to
> copy around to test recursive copy and move. I'm a bit reluctant to actually
> include this, any better suggestions? All I really care about is that there's
> a place with subdirectories that isn't huge. Maybe just cloud-robust or
> something so we have a place to create more complete configset examples? I
> don't want there to be a zillion configsets is all.
> ZkConfigManager already has recursive methods that the 'cp -r' and 'mv -r' zk
> commands could use if they were public (I've made them so temporarily with
> nocommits). This seems kind of A Bad Thing though since they're now
> mis-placed; the cp command has nothing to do with configuration management.
> Should these be moved to some new ZkUtil class or some such?
> Copying and moving when the destination is ZK is a bit strange in that parent
> znodes can have data too. So you get different behavior when copying, say,
> schema.xml -> 'zk:/configsets/myconfigs' as opposed to
> 'zk:/configests/myconfigs/' (notice trailing slash). This can lead to odd
> situations where you have content associated with, say,
> /configsets/myconfigs. On the one hand "that's just the way Zookeeper works".
> On the other it'll be surprising. Any suggestions on how to handle? I tried
> to be smart about making the decision based on whether the znode had
> children, but there's no reason one can't copy to
> 'zk:/wherever/something.txt' which has no children so relying on presence of
> children on the ZK nodes to figure out whether to put data in the node
> specified or a child breaks copying individual files to individual (new)
> files. And relying on data in a node precludes copying data to an empty
> ZNode. Perhaps provide a rmdata command to make it easy for people to recover
> the mistake?
> I don't yet have access to a Windows machine so anyone who wants to
> incorporate the changes to the bin/solr script to solr.cmd feel free ;). I'll
> get around to it "sometime", but sure would appreciate somebody who is more
> experienced than me with Windows programming taking it on. All that _should_
> have to be done is reflect the changes in bin/solr then run the new ... BTW,
> I did glance at that before my battery ran out on the plane and the use of
> '@echo' as opposed to 'echo' seems inconsistent.
> Speaking of Windows there's code around looking for a trailing slash. Can I
> rely on the Windows script to make sure the Java code only sees forward
> slashes or do I need to normalize that in the Java code? This is important to
> the point above about copying.
Thanks!
> 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
> Attachments: SOLR-9194.patch
>
>
> 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]
