On 2/25/2015 7:44 AM, Benson Margulies wrote:
> Shawn, I _am_ starting from clean. However, I didn't find a recipe for
> what you suggest as a process, and  (following Hoss' suggestion) I
> found the recipe above with the boostrap_confdir scheme.
>
> I am mostly confused as to how I supply my solrconfig.xml and
> schema.xml when I follow the process you are suggesting. I know I'm
> verging on vampirism here, but if you could possibly find the time to
> turn your paragraph into either a pointer to a recipe or the command
> lines in a bit more detail, I'd be exceedingly grateful.

I'm willing to help in any way that I can.

Normally in the conf directory for a non-cloud core you have
solrconfig.xml and schema.xml, plus any other configs referenced by
those files, like synomyms.txt, dih-config.xml, etc.  In cloud terms,
the directory containing these files is a confdir.  It's best to keep
the on-disk copy of your configs completely outside of the solr home so
there's no confusion about what configurations are active.  On-disk
cores for solrcloud do not need or use a conf directory.

The cloud-scripts/zkcli.sh (or zkcli.bat) script has an "upconfig"
command with -confdir and -confname options.

When doing upconfig, the zkHost value goes on the -z option to zkcli,
and you only need to list one of your zookeeper hosts, although it is
perfectly happy if you list them all.  You would point -confdir at a
directory containing the config files mentioned earlier, and -confname
is the name that the config has in zookeeper, which you would then use
on the collection.configName parameter for the Collections API call. 
Once the config is uploaded, here's an example call to that API for
creating a collection:

http://server:port/solr/admin/collections?action=CREATE&name=test&numShards=8&replicationFactor=1&collection.configName=testcfg&maxShardsPerNode=8

If this is not enough detail, please let me know which part you need
help with.

Thanks,
Shawn

Reply via email to