Part of this is a rant, part is a plea to others who've run successful production deployments.
Solr is a second-class citizen when it comes to production deployment. Every recipe I've seen (RPM, DEB, chef, or puppet) makes assumptions that in one way or another run afoul of best-practices when it comes to production use. And if you're not using one of these recipe formats to deploy Solr you're building a SnowflakeServer (Martin Fowler's term). Granted, Solr _can_ be deployed into any vanilla JEE container, so the deployment spec responsibility may be erroneously assigned to whichever you choose. BUT, if you want to get the maximum out of Solr you'll want to put it on its own box, running in its own tuned container, and that container should be the one that Solr's been tested on repeatedly by an army of build bots. Right now that blessed container is Jetty version 8.1.2.v20120308. So the first problem with the recipes is that they make a generic dependency of Jetty or Tomcat. The assumption there is that either can be treated as a generic OS facility to be shared with other apps. That's not true because Solr is the driving force behind which version is deployed. The container can't be up- or downgraded without affecting Solr, and any other app running in there needs to be aware that Solr is taking first priority. The next problem is that most recipes don't make a distinction between collections. "Solr" configuration goes in one folder, "Solr" data goes in another, and the logs and container stuff gets scattered likewise. In reality, every collection can be configured differently and there is no generic "Solr" data. Lastly, the package maintainers of all the major OS distributions have ignored Solr since around version 1.4. That means if you want a newer version you're going to download a tarball and make another snowflake. This might be attributable to thinking of Solr as just another web app that doesn't need special packaging. Regardless, the consequence is that the only people who are deploying Solr according to best-practices are those intimately familiar with Solr. So what's the best way to fix this situation? Solr already ships with everything it needs except Java and a start-up script. Maybe the first step is to include a generic "install.sh" script that has a couple distro-specific support scripts. That would be fairly agnostic toward package management systems and it would be useful to sysadmins right away. It would also help package maintainers update their build specs. What do _you_ think? -Scott
