On 22/07/2016 5:22pm, Aristedes Maniatis wrote: > But then what? In the production cluster it seems I then need to > > 1. Grab the latest configuration bundle for each core and unpack them > 2. Launch Java > 3. Execute the Solr jars (from the production server since it must be the > right version) > - with org.apache.solr.cloud.ZkCLI > - and some parameters pointing to the production Zookeeper cluster > - pointing also to the unpacked config files > 4. Parse the output to understand if any error happened > 5. Wait for Solr to pick up the new configuration and do any final production > checks
Shawn wrote:
> If you *do* want to run in cloud mode, then you will need to use zkcli to
> upload config changes to zookeeper and then issue a collection reload with
> the Collections API. This will find and reload all the cores related to that
> collection, across the entire cloud. You have the option of using the ZkCLI
> java class, or the zkcli.sh script that can be found in all 5.x and 6.x
> installs at server/scripts/cloud-scripts. As of version 5.3, the jars
> required for zkcli are already unpacked before Solr is started.
Thanks Shawn,
I'm trying to understand the common workflow of deploying configuration to
Zookeeper. I'm new to that tool, so at this point it appears to be a big black
box which can only be populated with data with a specific Java application.
Surely others here on this list use configuration management tools and other
non-manual workflows.
I've written a little gradle task to wrap up sending data to zookeeper:
task deployConfig {
description = 'Upload configuration to production zookeeper cluster.'
file('src/main/resources/solr').eachDir { core ->
doLast {
javaexec {
classpath configurations.zookeeper
main = 'org.apache.solr.cloud.ZkCLI'
args = [
"-confdir", core,
"-zkhost", "solr.host.com:2181",
"-cmd", "upconfig",
"-confname", core.name
]
}
}
}
}
That does the trick, although I've not yet figured out how to know whether it
was successful because it doesn't return anything. And as I outlined above, it
is quite cumbersome to automate. Are you saying that everyone who runs
SolrCloud runs all these scripts against their production jars by hand?
Zookeeper seems a step backward from files on disk in terms of ease of
automation, inspecting for problems, version control and a new point of failure.
Perhaps because I'm new to it I'm missing a set of tools that make all that
much easier. Or for that matter, I'm missing an understanding of what problem
Zookeeper solves.
Ari
--
-------------------------->
Aristedes Maniatis
CEO, ish
https://www.ish.com.au
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
signature.asc
Description: OpenPGP digital signature
