Ok, that makes sense and it's probably workable, but, it's still more awkward than having code and configuration deployed together to individual machines.
For example, for a deploy of new software/config we need to 1) first upload config to zK. then 2) deploy new software to the nodes. What about the span of time between 1) and 2)? If a box bounces during this time it will come up with the wrong config. Or what if 2) goes awry and some boxes succeed and some fail? It could be very complicated to recover from that. Another use case is, I may want to push a new software/config to a single box for a smoke test before rolling to all nodes in production (some might call this testing in production but it's just real world safety). I guess at the end of the day, what I don't understand is, given that I need to roll new software bits to individual nodes for the deployment of new software, what good does keeping config in zk do for me? Why not just keep the config with the software and roll it at the same time? -- View this message in context: http://lucene.472066.n3.nabble.com/Rolling-Deploys-and-SolrCloud-tp4026212p4026419.html Sent from the Solr - User mailing list archive at Nabble.com.
