geerlingguy / ansible-role-solr Goto Github PK
View Code? Open in Web Editor NEWAnsible Role - Apache Solr
Home Page: https://galaxy.ansible.com/geerlingguy/solr/
License: MIT License
Ansible Role - Apache Solr
Home Page: https://galaxy.ansible.com/geerlingguy/solr/
License: MIT License
When trying to install solr through this role, it fails at the cores.yml task. When I remove this task from the role file (because I have no cores defined anyway, I want an empty solr install) it runs fine. My guess is that is somehow doesn't parse the response of the URL correctly to find the list of current cores (there are none in my case).
fatal: [cluster-worker000000]: FAILED! => {"failed": true, "msg": "The conditional check ''{{ item }}' not in '{{ solr_cores_current.content }}'' failed. The error was: Invalid conditional detected: EOL while scanning string literal (<unknown>, line 1)\n\nThe error appears to have been in '/home/rose/.ansible/roles/geerlingguy.solr/tasks/cores.yml': line 8, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Ensure Solr conf directories exist.\n ^ here\n"}
fatal: [cluster-worker000001]: FAILED! => {"failed": true, "msg": "The conditional check ''{{ item }}' not in '{{ solr_cores_current.content }}'' failed. The error was: Invalid conditional detected: EOL while scanning string literal (<unknown>, line 1)\n\nThe error appears to have been in '/home/rose/.ansible/roles/geerlingguy.solr/tasks/cores.yml': line 8, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Ensure Solr conf directories exist.\n ^ here\n"}```
Just a quick question as I'm in the process of working out how to automate solr cores on installations using major versions 3-6.
The solr core creation script only came into place officially in version 5, what would be your recommended method of automation for versions 3 and 4?
I understand this has no real chance of becoming a part of the workflow of this role, but I believe the question is worth asking.
https://docs.ansible.com/ansible/systemd_module.html reports that systemd
module is available as of Ansible 2.2
This should be mentioned somewhere in the release notes at https://github.com/geerlingguy/ansible-role-solr/releases/tag/3.2.3 to prevent people from hitting a wall when running the install.yml
playbook.
In Drupal VM (see geerlingguy/drupal-vm#789), some have noticed that the combo of this role and CentOS 7 results in the following fail:
TASK [geerlingguy.solr : Ensure solr is started and enabled on boot.] **********
fatal: [drupalvm]: FAILED! => {"changed": false, "failed": true, "msg": "Job for solr.service failed because the control process exited with error code. See \"systemctl status solr.service\" and \"journalctl -xe\" for details.\n"}
It looks like the systemctl
config for Solr (at least 5.x) might not be configured correctly... going to look into this.
Hey,
My playbook:
---
- hosts: all
become: yes
roles:
- { role: geerlingguy.java }
- { role: geerlingguy.solr, solr_version: "4.10.4" }
Fails on this task:
TASK [geerlingguy.solr : Ensure solr is started and enabled on boot.] **********
fatal: [192.168.104.11]: FAILED! => {"changed": false, "failed": true, "msg": "Could not find the requested service \"'solr'\": "}
See full output here: http://pastebin.com/w3CSYCSa
I'm using your geerlingguy/ubuntu1604 vagrant box, ansible 2.2.0.0 and release 3.4.1 of this role.
I was able to work around the issue if I run this command in the vagrant machine:
sudo update-rc.d solr defaults
Any thoughts?
In the init script for debian the variable "provides" is hardcoded to "solr". When you want to spinup multible solr versions, the result is that you get an error when the secode service is registered.
It think
# Provides: solr
should be
# Provides: {{ solr_service_name }}
Because this variable is used when the service is registed in Ubuntu 16.04 as system service.
https://github.com/geerlingguy/ansible-role-solr/blob/master/templates/solr-init-Debian-pre5.j2#L12
See geerlingguy/drupal-vm#1028
TASK [geerlingguy.solr : Apply Solr memory configuration changes.] *************
failed: [drupalvm] (item={u'regexp': u'^.?SOLR_JAVA_MEM=', u'line': u'SOLR_JAVA_MEM="-Xms64M -Xmx128M"'}) => {"failed": true, "item": {"line": "SOLR_JAVA_MEM=\"-Xms64M -Xmx128M\"", "regexp": "^.?SOLR_JAVA_MEM="}, "msg": "Destination /etc/default/solr.in.sh does not exist !", "rc": 257}
failed: [drupalvm] (item={u'regexp': u'^SOLR_PORT=', u'line': u'SOLR_PORT="8983"'}) => {"failed": true, "item": {"line": "SOLR_PORT=\"8983\"", "regexp": "^SOLR_PORT="}, "msg": "Destination /etc/default/solr.in.sh does not exist !", "rc": 257}
I am using this role as part of DrupalVM. I have set solr_version
to 4.5.1.
SOLR installs correctly (at least as far as the Ansible tasks dictate), but the service never starts. However, when running the init.d version of the script, it works fine:
$ sudo /etc/init.d/solr start
I was wondering why it doesn't do the same thing when run as sudo service solr start
. Then I realized that Ubuntu 16.04 uses systemd which does not use the init.d script. I saw the systemd version of the file and saw the problem.
ExecStart={{ solr_install_path }}/bin/solr -e cloud -noprompt
The {{ solr_install_path }}/bin
directory on SOLR 4.5.1 is empty. To make sure that this is not a packaging problem, I even cross-checked it with SOLR 4.9.1 and it was still empty. I am assuming this is true for all 4.x releases. As a side note, the configure-solr.sh
included in DrupalVM doesn't work for the same reason.
I see the above being changed in #56 but that has not been merged yet. I know there is a reason that is not merged yet and I want to bring this issue to your attention as well.
It seems that Solr 5.x, at least, leaves a decent amount of cruft in the default install, e.g.:
90M /opt/solr-6.4.0/docs
8.3M /opt/solr-6.4.0/example
Those are easy wins if we can just drop them through the use of a variable like solr_remove_cruft
.
I'll have to verify they're named similarly in older Solr releases (besides just 5.x and 6.x).
Apparently I never tested the solr_remove_cruft
option on Solr 4.x (or below)—and I've run into this error when building out my Solr Docker image. See: geerlingguy/solr-container#6
The error message I get is:
Solr home directory /opt/solr/example/solr not found!
When installing Solr version 4.10.4 with the latest release of this role, Solr doesn't read the solr cores from the correct path, which would be {{ solr_home }}
(defaults to /var/solr
).
Rather the cores are read from /opt/solr/node1/solr, that is from the solr install path. See screenshot from the solr admin tool:
I'm using geerlingguy/ubuntu1604 vagrant box, ansible 2.2.0.0 and release 3.4.2 of this role.
My playbook is
---
- hosts: all
sudo: yes
vars:
solr_version: "4.10.4"
solr_cores:
- common
roles:
- geerlingguy.java
- geerlingguy.solr
post_tasks:
- name: Remove default core
file:
path: "{{ solr_home }}/collection1"
state: absent
when: solr_cores is defined
- name: Create solr core paths
file:
path: "{{ solr_home }}/{{ item }}"
state: directory
owner: "{{ solr_user }}"
group: "{{ solr_user }}"
with_items: "{{ solr_cores }}"
when: solr_cores is defined
- name: Copy solr core configs
copy:
src: "solr-cores/{{ item }}/"
dest: "{{ solr_home }}/{{ item }}"
owner: "{{ solr_user }}"
group: "{{ solr_user }}"
with_items: "{{ solr_cores }}"
notify: restart solr
when: solr_cores is defined
The core I'm using looks like this
core.properties:
name=common
The conf
dir is identical to the one from Drupal's search_api_solr module, http://cgit.drupalcode.org/search_api_solr/tree/solr-conf/4.x
Hello!
Thank for this role, it is very useful!
and - will you add support of clusters?
Since it's out, and the default is currently 6.3.0.
SHA1 sum is 2cc43b837743949a46bd7efbab14b43f6d92b4b8
currently.
I have a strange problem, after installing this role on a Debian Jessie, daemon is started with user 'root', and error org.apache.solr.common.SolrException: java.io.FileNotFoundException: /var/solr/collection1/data/tlog/tlog.0000000000000000000
is displayed at log console on Solr admin. I need to manually stop daemon and run su -c "/etc/init.d/solr start solr" solr
to run daemon with solr user at least once. And only then data directory is created and initializated.
I expected process owner to be solr always, even when we run service solr start
as root.
As the title says.
I am getting a new warning when using this role in a build:
- downloading role 'solr', owned by geerlingguy
[WARNING]: geerlingguy.solr is a Container Enabled role and should only be installed using Ansible Container
Though looking at https://github.com/geerlingguy/solr-container it seems this role is meant to work both with Ansible Container and standalone, and this can be ignored, is that right? Is there a way to suppress this warning?
I'm having an issue with restarting solr 4.10 on Centos 7. Calling restart via the handler causes solr to stop, but it does not restart.
I've already hit an issue with solr not starting due to the daemon needing to be reloaded, so I've copied the 5+ logic into the pre5-install.yml
tasks but I'm really having trouble sussing out why the restart command is not working.
If I run the commands at the command line, I see a similar issue. If I have a running solr and issue systemctl restart solr
, the solr process stops (the log ends with org.eclipse.jetty.util.thread.ShutdownThread – shutdown already commenced
, but is not restarted.
If I then issue a systemctl status solr
it outputs:
● solr.service - SYSV: Controls an Apache Solr process.
Loaded: loaded (/etc/rc.d/init.d/solr)
Active: active (exited) since Thu 2016-12-15 19:48:37 UTC; 2min 35s ago
Docs: man:systemd-sysv-generator(8)
Dec 15 19:48:37 dangerzone.mydomain systemd[1]: Starting SYSV: Controls an Apache Solr process....
Dec 15 19:48:37 dangerzone.mydomain solr[12063]: Starting solr... already started... done.
Dec 15 19:48:37 dangerzone.mydomain systemd[1]: Started SYSV: Controls an Apache Solr process..
Any thoughts? Happy to test things and submit a PR if you can point me in the right direction.
Current service behaviour:
User | start | stop | status | restart |
---|---|---|---|---|
root | OK | OK | OK | OK |
solr | Error | OK | OK | Error |
other | Error | OK | OK | Error |
Desired service behaviour:
User | start | stop | status | restart |
---|---|---|---|---|
root | OK | OK | OK | OK |
solr | OK | OK | OK | OK |
other | Message | Message | OK | Message |
Suggestions:
Comments?
5.x is another large change to the entire Solr deployment/configuration process, as it no longer supports other Java servlet containers out of the box, and relies instead on built-in tooling.
The recommended setup uses a shell script with command line flags, but we can do better than that (what is this, 1999? Who logs into servers anymore?).
See:
I did a lot of the ground work in #8, but there are still some things that need to be changed to get 5.x deployed and configured correctly out of the box. So far, since none of the projects I'm working on even have rudimentary support for 5.x (they're all only recently updated for later versions of 4.x!), this isn't a pressing issue. But I would like to be able to get the role to support at least 4.x and 5.x, if not 3/4/5.
ansible-role-solr/tasks/main.yml
Line 3 in 1536d6c
Even though the "when" is specified when Include: user.yml, the file gets included unconditionally and breaks the build in some cases.
"when" does not work with "include" statements and should be used in individual tasks instead.
Using Ubuntu's init script, which uses daemon
from libslack to daemonize Solr, the service solr stop
command returns immediately, even though solr hasn't yet shut down. Then Ansible runs service solr start
immediately after, reports success on a restart, and the playbook completes.
However, this results in solr being stopped instead, which is not desirable.
I really would like to find a simple way to daemonize solr with a better and cross-platform init script, but at this point, I'll be happy just adding a sleep
parameter to the restart solr
handler.
I'm getting inconsistent results when using this role (3.4.1) with Debian Jessie.
On the first run I'll get:
TASK [geerlingguy.solr : Create configured cores.] *****************************
changed: [203.0.113.13] => (item=collection1)
TASK [geerlingguy.solr : debug] ************************************************
ok: [203.0.113.13] => {
"msg": {
"changed": true,
"msg": "All items completed",
"results": [
{
"_ansible_item_result": true,
"_ansible_no_log": false,
"_ansible_parsed": true,
"changed": true,
"cmd": "/opt/solr/bin/solr create -c collection1",
"delta": "0:00:02.713352",
"end": "2017-01-16 17:13:00.886274",
"invocation": {
"module_args": {
"_raw_params": "/opt/solr/bin/solr create -c collection1",
"_uses_shell": true,
"chdir": null,
"creates": null,
"executable": null,
"removes": null,
"warn": true
},
"module_name": "command"
},
"item": "collection1",
"rc": 0,
"start": "2017-01-16 17:12:58.172922",
"stderr": "",
"stdout": "\nCreating new core 'collection1' using command:\nhttp://localhost:8983/solr/admin/cores?action=CREATE&name=collection1&instanceDir=collection1\n\n{\n \"responseHeader\":{\n \"status\":0,\n \"QTime\":2154},\n \"core\":\"collection1\"}",
"stdout_lines": [
"",
"Creating new core 'collection1' using command:",
"http://localhost:8983/solr/admin/cores?action=CREATE&name=collection1&instanceDir=collection1",
"",
"{",
" \"responseHeader\":{",
" \"status\":0,",
" \"QTime\":2154},",
" \"core\":\"collection1\"}"
],
"warnings": []
}
]
}
}
Which is expected, since the Solr core doesn't exist yet.
What's more surprising is on subsequent runs I'll get:
TASK [geerlingguy.solr : Create configured cores.] *****************************
...ignoring
failed: [203.0.113.13] (item=collection1) => {"changed": true, "cmd": "/opt/solr/bin/solr create -c collection1", "delta": "0:00:00.681810", "end": "2017-01-16 17:13:41.423812", "failed": true, "item": "collection1", "rc": 1, "start": "2017-01-16 17:13:40.742002", "stderr": "\nERROR: \nCore 'collection1' already exists!\nChecked core existence using Core API command:\nhttp://localhost:8983/solr/admin/cores?action=STATUS&core=collection1", "stdout": "", "stdout_lines": [], "warnings": []}
TASK [geerlingguy.solr : debug] ************************************************
ok: [203.0.113.13] => {
"msg": {
"changed": true,
"failed": true,
"msg": "One or more items failed",
"results": [
{
"_ansible_item_result": true,
"_ansible_no_log": false,
"_ansible_parsed": true,
"changed": true,
"cmd": "/opt/solr/bin/solr create -c collection1",
"delta": "0:00:00.681810",
"end": "2017-01-16 17:13:41.423812",
"failed": true,
"invocation": {
"module_args": {
"_raw_params": "/opt/solr/bin/solr create -c collection1",
"_uses_shell": true,
"chdir": null,
"creates": null,
"executable": null,
"removes": null,
"warn": true
},
"module_name": "command"
},
"item": "collection1",
"rc": 1,
"start": "2017-01-16 17:13:40.742002",
"stderr": "\nERROR: \nCore 'collection1' already exists!\nChecked core existence using Core API command:\nhttp://localhost:8983/solr/admin/cores?action=STATUS&core=collection1",
"stdout": "",
"stdout_lines": [],
"warnings": []
}
]
}
}
The error Core 'collection1' already exists!
shouldn't be happening in the first place because we should have been able to test that the default Solr core already exists.
I've been thinking about simply checking that collection1
exists but that wouldn't be that simple because, as I understand, solr_cores
is an array of cores that we should potentially be ready to check for should they have been defined.
Is it me doing something foolish or could we possibly improve the conditions such as we're making this task more solid?
I discovered this issue while setting up multiple cores in non-default location, see: https://github.com/geerlingguy/ansible-role-solr/blob/master/tasks/cores.yml where {{solr_home}}
should be used.
Currently only 3.x and 4.x are tested in Ubuntu 12.04.
First, I want to make sure 5.x is tested.
Then I want to test under RedHat + Ubuntu (at least the latest LTS releases of each) for at least 6.x and 5.x of Solr, and also run tests on 3.x/4.x on Ubuntu 14, maybe.
Thank you for this role! I tested out using this role with Debian wheezy but it looks like that is unsupported?
TASK: [geerlingguy.solr | Ensure solr is started and enabled on boot.] ********
failed: [33.33.33.24] => {"failed": true}
msg: update-rc.d: error: solr Default-Start contains no runlevels, aborting.
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.5 (wheezy)
Release: 7.5
Codename: wheezy
Branched off from #2 - right now you have to do a little extra work after the initial provisioning to get multicore working off the bat (without going into the Solr UI).
Right now the tests only branch the current default version of Solr. I'd like to at least test 3.x and 4.x for now, and soon also 5.x (once I officially commit to supporting 5.x).
I'm running into this error on my clean copy of drupal-vm:
TASK [geerlingguy.solr : Download Solr.] ***************************************
fatal: [collegescorecard]: FAILED! => {"changed": false, "failed": true, "msg": "failed to create temporary content file: timed out"}
I tried running vagrant provision
again a few times but appear to be getting the same error.
My config.yml isn't too far from the example config, other than uncommenting solr
from installed_extras, using Drupal 7 and not installing the site or running the make file on provision.
Hi Jeff,
thank you for the role, it works fine for the default version 3.6.2. Starting with 4.1.0 Solr package name has been changed from "apache-solr-..." to just "solr..." (http://archive.apache.org/dist/lucene/solr/4.1.0/), which cause following error, when I try to change version to 4.8.0:
ASK: [geerlingguy.solr | Download Solr.] *************************************
failed: [default] => {"dest": "/root/apache-solr-4.8.0.tgz", "failed": true, "item": "", "response": "HTTP Error 404: Not Found", "state": "absent", "status_code": 404, "url": "http://archive.apache.org/dist/lucene/solr/4.8.0/apache-solr-4.8.0.tgz"}
msg: Request failed
Thanks in advance.
Imagine a scenario where you provide all binary archives and other external resources on a read-only NFS server, for example. In this scenario, you would like to read archives from NFS but expand their contents somewhere else.
In other words, create an additional {{ solr_downloads }}
which is intended to keep the download binary. If it is already there, like in the example of a read-only NFS server, nothing needs to be downloaded.
I know you maintain a lot of roles (thank you!) so I hope it's helpful to flag the new versions of Solr that are out: https://lucene.apache.org/solr/news.html
On my system (ubuntu 16.04) i've got the problem that new services can only be started on boot when i pass
daemon_reload: yes
I would propose to add this as a property after the setup, otherwise the service a not visible.
I took this for a spin, both with the solr box in your Ansible Vagrant Examples as well as in my own test ansible project. In both cases I get a 404 navigating to [host]:8080/solr, but as far as I can tell all the tasks ran successfully on provision. The 404 is provided by tomcat, so it looks like things are almost setup but not quite finishing. Not sure what else to provide on this since the provision seems successful, but if there's anything I can provide to help with this let me know.
I've been using your role for a while and this has just cropped up with the latest version.
Any tips on how to navigate?
Since 2.0 is pretty much everywhere, we can use unarchive
s ability to download and expand-into-place the Solr archive.
Currently, the download file sits on the system after the role is finished, but that's annoying... it's like 150MB! And it's causing downstream projects to also be larger than necessary. See, for example: https://github.com/geerlingguy/docker-image-solr/issues/5
Basically, with Ansible 2.x, we should be able to combine these two tasks:
- name: Download Solr.
get_url:
url: "{{ solr_mirror }}/lucene/solr/{{ solr_version }}/{{ solr_filename }}.tgz"
dest: "{{ solr_workspace }}/{{ solr_filename }}.tgz"
force: no
- name: Expand Solr.
unarchive:
src: "{{ solr_workspace }}/{{ solr_filename }}.tgz"
dest: "{{ solr_workspace }}"
creates: "{{ solr_workspace }}/{{ solr_filename }}/CHANGES.txt"
copy: no
Also, related: #14
Right now the initial install (at least via Travis CI) returns:
The command "grep -q 'changed=0.*failed=0'" exited with 0.
$ curl http://localhost:8080/solr/core0/admin/ping
<html><head><title>Apache Tomcat/6.0.35 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The requested resource () is not available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/6.0.35</h3></body></html>
With Solr 4.x, it requires the openjdk-7-jdk
installed (rather than version 6). I'm testing an updated test.yml file...
In Solr 4.x and below, the custom init script included with this role passes along java options like solr_xms
and solr_xmx
in the start command... in Solr 5.x+, the install script sets everything up for us, and uses an include file for extra settings (see: https://cwiki.apache.org/confluence/display/solr/Taking+Solr+to+Production#TakingSolrtoProduction-MemoryandGCSettings).
We could set the variable correctly like so, in that include file:
SOLR_JAVA_MEM="-Xms{{ solr_xms }} -Xmx{{ solr_xmx }}"
Right now, even though tests are passing, the initial installation fails because the multicore configuration used by this role is a little brittle.
Though curl exits with a 0 status (I should really check the response headers and parse them in the test), it returns the Tomcat error page:
$ curl http://localhost:8080/solr/core0/admin/ping
<html><head><title>Apache Tomcat/6.0.35 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The requested resource () is not available.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/6.0.35</h3></body></html>
On a pre-Solr 5 install on CentOS 6 I am getting an error, because systemd is not installed:
TASK [geerlingguy.solr : Copy solr systemd unit file into place (for systemd systems).] ***
fatal: [127.0.0.1]: FAILED! => {"changed": true, "failed": true, "msg": "Destination directory /etc/systemd/system does not exist"}
I don't immediately see why this is happening because the when
clause should be skipping this step:
$ ansible -ilocalhost, all --connection local -m setup -a 'filter=ansible_distribution*'
localhost | SUCCESS => {
"ansible_facts": {
"ansible_distribution": "CentOS",
"ansible_distribution_major_version": "6",
"ansible_distribution_release": "Final",
"ansible_distribution_version": "6.9"
},
"changed": false
}
Would it be simpler to check for the existence of the directory and put the unit file into place only if it exists?
https://github.com/geerlingguy/ansible-role-solr/blob/master/tasks/install.yml#L15 you rely on solr
as service name here, because if i change it to haystack
the install directory is: /opt/haystack/
and your creates statement is wrong.
In --check
mode the task Check current list of Solr cores.
is skipped thus solr_cores_current
is never populated. This means that the subsequent Ensure Solr conf directories exist.
fails with:
FAILED! => {"failed": true, "msg": "The conditional check 'item not in solr_cores_current.content' failed. The error was: error while evaluating conditional (item not in solr_cores_current.content): Unable to look up a name or access an attribute in template string ({% if item not in solr_cores_current.content %} True {% else %} False {% endif %}).\nMake sure your variable name does not contain invalid characters like '-': argument of type 'StrictUndefined' is not iterable
Right now the service
management is hardcoded—when you run this role, the role presumes you will want to run solr
under sysvinit or systemd, and further, that you want it started
. I would like to add two variables:
solr_service_manage
— defaults true
, if false
, the service
task is skipped entirely.solr_service_state
— defaults started
, but user can control whether solr is stopped if running, restarted, etc. as needed.This is especially helpful from the perspective of making the role work inside containers, which may not even have an init system running.
I see that there is already discussions around v5. Thoughts on v6?
See: https://cwiki.apache.org/confluence/display/solr/Running+Solr#RunningSolr-CreateaCore
$ bin/solr create -c <name>
For available options:
$ bin/solr create -help
The new solr.xml format (https://cwiki.apache.org/confluence/display/solr/Format+of+solr.xml) makes it a lot easier to auto-discover cores and removes the need for hardcoding the 2 cords that are currently mentioned in this role. We will still need a default core, but the configuration is much simplified as per the above example.
I was able to modify your role using the above to get this to work, the only quirk being that solrconfig.xml has relative paths to some of the jars in the "contrib" and "dist" folder which I had to fix manually (but can be done through the role itself). This wasnt a problem in the way the role is currently available but inside example/multicore/core0/conf/solrconfig.xml is this statement
<!--
This is a stripped down config file used for a simple example...
It is *not* a good example to work from.
-->
Instead using the example/solr/collection1/conf/solrconfig.xml has a more complete configuration file, but has the reference issue that I mentioned above.
I can provide a PR if thats okay with you, quite new to ansible roles, so might need some work before I send it out to you.
Solr has improved quite a bit since the initial version of this role was written (for early 3.x versions of Solr). In Solr 4.x and now 5.0.0 (just released), it's preferred to use the included Jetty-based servlet, which is simpler to install and configure than Tomcat.
Plus, I only have a crufty old 'tomcat6' role to use, and don't have any other projects where I use Tomcat anymore, so there's no real reason for me to create or update tomcat roles. And since Jetty's preferred anyways, and should have comparable performance nowadays... no reason not to use Jetty :)
So I'm going to completely rewrite the role, and still hopefully be able to support any version of Solr from 3.x to 5.x, installed with Java 7+. I can also drop the dependency on geerlingguy.tomcat6
, and just have no dependencies (people can install Java however they please... though the geerlingguy.java
role makes this simple as well).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.