solr_wrapper
solr_wrapper copied to clipboard
cbeer
Fix clean etc
Might fix #83
solr_wrapper clean was often reporting that solr has to be stopped before cleaning it, when solr was never running in the first place. This bugged me often enough that it motived a fork and these changes. Throwing up this PR for consideration, maybe it's useful upstream.
Added some other command-line utils, including status and stop. They are working for me. No specs needed to change for this PR, everything was passing OK on my laptop.
Example of using this branch:
$ solr_wrapper
Starting Solr 6.5.1 on port 8983 ... http://127.0.0.1:8983/solr/
^Z
[1]+ Stopped solr_wrapper
$ bg
[1]+ solr_wrapper &
$ solr_wrapper status
Found 1 Solr nodes:
Solr process 8460 running on port 8983
{
"solr_home":"/tmp/solr-6.5.1/server/solr",
"version":"6.5.1 cd1f23c63abe03ae650c75ec8ccb37762806cc75 - jimczi - 2017-04-21 12:23:42",
"startTime":"2017-05-10T23:56:49.492Z",
"uptime":"0 days, 0 hours, 0 minutes, 17 seconds",
"memory":"18.3 MB (%3.7) of 490.7 MB"}
$ solr_wrapper stop
$ solr_wrapper status
No Solr nodes are running.
[1]+ Done solr_wrapper
Addressed comments, leaving commits for checking details, can squash as required later.
This gem doesn't require rails, so a dependency on RAILS_ENV is inappropriate.
it is a very common practice for gems that don't depend on/require rails to still check for RAILS_ENV. Developers who are using Rails find it very convenient, and there's really no cost to the gem to do it.
Often gems will first check for a "${GEM_NAME}_ENV", lazily resorting to RAILS_ENV only if it's not present, so people not using Rails can still use an ENV setting without inaccurately calling it RAILS_ENV. Because having env-specific config is very common, even without Rails, and for those using Rails falling through to RAILS_ENV is very convenient.
I disagree with avoiding this develper convenience in the name of some kind of purity that has really no cost at all.
Examples: Many web servers use both RACK_ENV or RAILS_ENV, although they can work with any rack app, not just rails.
Sidekiq also uses RAILS_ENV, although it has no dependency on rails. https://github.com/mperham/sidekiq/blob/3b00587ea0b3f887df9053ee2f6b42a69481b5ce/lib/sidekiq/cli.rb#L211
An alternative might be allowing setting of 'ENV' in the .solr_wrapper file (which is run through erb), so the user could choose to set it to <%= ENV['RAILS_ENV'] %> -- but of course the problem is that under the common usage, which config file to load depends on the env, so it's too late.
That said, I'm not sure what this PR is doing with RAILS_ENV is what I'd do, but it still seems like progress to me. Things get very confusing at present, anything to reduce the confusion would be great.
In my ideal world, I'd have one config file that had env-specific development: test: etc keys, and have that convention established by this gem. Currently, without the gem supplying any support for this, different downstream consumers who still need env-specific config are left to their own devices, and what activefedora has decided, to put the development config in .solr_wrapper but the test config in config/test_solr_wrapper.yml is awfully confusing. While the downstream consumers could make differnet less confusing decisions -- they couldn't easily actually put everything in one file without support from the upstream solr_wrapper gem.
$ bundle exec solr_wrapper -h
Usage: solr_wrapper [options] subcommand
-v, --[no-]verbose Run verbosely
--config FILE Load configuration from a file
--version VERSION Specify a Solr version to download (default: latest)
-p, --port PORT Specify the port Solr should run at (default: 8983)
-c, --cloud Run solr in cloud mode
--solr_zip_path PATH Download/use solr at the given path
-i, --instance_directory DIR Install/use solr at the given directory
-l, --lib_directory DIR Grab extra libs from this directory
-n, --collection_name NAME Create a default solr collection with the given name
-d, --collection_config DIR Create a default solr collection with the files from the given directory
--[no-]persist Persist the solr connection data
--no-checksum Skip running checksum validation on the downloaded file
Commonly used command are:
clean : stop and clean data from solr, then create a new instance
purge : as in 'clean', but this also removes solr download files
dir : prints the solr instance dir
status : information about running solr cores
stop : stop a running solr core
See 'solr_wrapper COMMAND --help' for more information on a specific command.
Obviously some squashing is required before a merge. I'm only leaving individual commits for the sake of review in the PR, to help track the review requirements/discussion.
My ~/.solr_wrapper.yml uses download dir: ~/tmp/solr_wrapper
$ bundle exec solr_wrapper clean
cleaning solr instance: /tmp/solr-6.5.1 ...
$ ll ~/tmp/solr_wrapper/solr-6.5.1*
-rw-r--r-- 1 dlweber users 144M May 5 12:58 /users/dlweber/tmp/solr_wrapper/solr-6.5.1.zip
-rw-r--r-- 1 dlweber users 49 May 10 16:04 /users/dlweber/tmp/solr_wrapper/solr-6.5.1.zip.md5
$ bundle exec solr_wrapper purge
cleaning solr downloads and solr instance: /tmp/solr-6.5.1 ...
$ ll ~/tmp/solr_wrapper/solr-6.5.1*
ls: cannot access '/users/dlweber/tmp/solr_wrapper/solr-6.5.1*': No such file or directory