Create cores task fails about ansible-role-solr

[geerlingguy]

@JugglerX / @choicelildice - You can also just try setting the following in your config.yml / whatever other settings file:

solr_cores: []

That basically tells this role to keep it's hands off Solr cores.

[JugglerX]

I am having the same issue

I have done a fresh install on the latest Drupal VM (4.4.0 "Sea of Simulation" according to the CHANGELOG.md)

I downloaded drupalvm
I used the default.config.yml and uncommented the lines relevant to enabling solr.

I uncommented - solr

installed_extras:
  - adminer
  # - blackfire
  - drupalconsole
  - drush
  # - elasticsearch
  # - java
  - mailhog
  # - memcached
  # - newrelic
  # - nodejs
  - pimpmylog
  # - redis
  # - ruby
  # - selenium
  - solr
  # - tideways
  # - upload-progress
  - varnish
  # - xdebug
  # - xhprof

I uncommented - "../examples/scripts/configure-solr.sh"

post_provision_scripts:
  - "../examples/scripts/configure-solr.sh"

i ran vagrant up

I get the following error

TASK [geerlingguy.solr : Run Solr installation script.] ************************
ok: [drupalvm]

TASK [geerlingguy.solr : Ensure solr is stopped (RHEL 7 workaround).] **********
skipping: [drupalvm]

TASK [geerlingguy.solr : Run systemd daemon_reload (RHEL 7 workaround).] *******
skipping: [drupalvm]

TASK [geerlingguy.solr : Ensure solr is started and enabled on boot.] **********
ok: [drupalvm]

TASK [geerlingguy.solr : Check current list of Solr cores.] ********************
ok: [drupalvm]

TASK [geerlingguy.solr : Ensure Solr conf directories exist.] ******************
fatal: [drupalvm]: 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 '/vagrant/provisioning/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"}
	to retry, use: --limit @/vagrant/provisioning/playbook.retry

[choicelildice]

Same exact issue here.

[geerlingguy]

I'll try to take a look at this later.

Note that the defaults create one default core, collection1 (https://github.com/geerlingguy/ansible-role-solr/blob/master/defaults/main.yml#L22-L23), and the automated tests work for just that core.

The conditional check ''{{ item }}' not in '{{ solr_cores_current.content }}'' failed.

I wonder if this could be an Ansible version discrepancy... Can all of you check and see what Ansible version you're running?

I'm on 2.2.1, and I know there have been some bugs with some variable things in 2.1.x versions (and maybe 2.0.x as well).

[choicelildice]

Thanks Jeff,

Honestly, I'm always impressed by how responsive you are. Here are a few more details. I'm on version 2.2.0. I am actually not having the issue, but a colleague of mine is. We are BOTH on 2.2.0 for ansible, as I thought that might be the issue as well. I have set up this vagrant box in the past, but continue to have NO issues, even when destroying and recreating. Running the same configuration as me (same git repository) my colleague hits this issue every time he runs vagrant up. Happy to provide more info if you need it.

[geerlingguy]

@choicelildice - hmm, good to know. In that case, do you know if your colleague is using Linux, macOS, or Windows, and also what editor he might be using? Maybe it's a line ending issue?

Are you using the exact same configuration (e.g. stored in git and checked out by both of you), or is this configuration managed individually?

[JugglerX]

So i've been troubleshooting this issue since yesterday.

I tried older versions of Drupal VM / Virtual Box
I even tried a fresh drupalvm install on another physical machine.

the error kept happening.

I'm no expert with Ansible, so this is my rough working theory. As the OP mentioned, it appears that in cores.yml (provisioning/roles/geerlingguy.solr/tasks/cores.yml) there is some logic that checks if cores exist and if not, it creates them. For whatever reason either {{ item }} or {{solr_cores_current.content }} is not set correctly? So it throws this error.

The only workaround I have found, which is certainly not a long-term solution is as follows:

Comment out lines 50 & 51 from main.yml (provisioning/roles/geerlingguy.solr/tasks/main.yml)

# Create cores, if any are configured.
# - include: cores.yml
#   when: "solr_cores and solr_version.split('.')[0] >= '5'"

This basically prevents the cores.yml from running. From my understanding cores.yml is supposed to create the solr cores, ie: "collection1" (which is important)

The thing is, when enabling - solr in default.config.yml we also uncomment the post provisioning script - "../examples/scripts/configure-solr.sh" that sets up the solr schema for Drupal. This script will infact create a core for you anyway.

So you don't appear to really need the cores.yml file, and you can just rely on the post provisioning script to create the core.

So. Comment out the cores.yml file, enable solr and enable the post provision script and vagrant up should work, and a core should be created.

[choicelildice]

Thanks @JugglerX we can try that.

[choicelildice]

@geerlingguy He is using macOS. Same as me. Does destroying the vagrant box remove the cores? I wonder if mine is working because those cores already exist? Just a theory, if destroying removes them, then my theory probably isn't right. We are using the exact same config, stored in git.

[geerlingguy]

@choicelildice - Yeah, if you destroy the vagrant box, that will wipe out everything inside (including the cores this role would create).

[geerlingguy]

And as another data point, when building a demo Drupal VM build (the one powering http://prod.drupalvm.com/), I've added Solr to it and both on DigitalOcean and locally the core step succeeds. Definitely a head scratcher why some people are running into this and others aren't!

[choicelildice]

yeah, we have tried downgrading vagrant to the same version I'm on (1.8.7.... i know old...). I try not to bug you with issues here unless I've ruled out the obvious. We haven't had anyone else on this project have the same issue, just this one person. I agree, a head scratcher. I like that there is a workaround though, we can try that in the meantime, and I'm happy to test any suggestions you can think of.

[JugglerX]

I have not installed Ansible locally. I let Vagrant install Ansible each time I vagrant up. I am using Mac.

@geerlingguy - that is a more elegant work around, good idea.

[Sardis93]

I'm having the same problem. Using Ubuntu 16.04 on DigitalOcean.
Latest Ansible, geerlingguy.java, geerlingguy.solr versions.

Here's my playbook:

---
- name: Install solr
  hosts: localhost
  become: yes
  become_method: sudo

  vars:
    solr_version: 5.4.1

  roles:
    - geerlingguy.java
    - geerlingguy.solr

Here's what i have in the {{ solr_cores_current }}:

{u'changed': False,
 u'connection': u'close',
 u'content': u'<?xml version="1.0" encoding="UTF-8"?>\n<response>\n<lst name="responseHeader"><int name="status">0</int><int name="QTime">5</int></lst><lst name="initFailures"/><lst name="status"/>\n</response>\n',
 u'content_type': u'application/xml; charset=UTF-8',
 u'msg': u'OK (unknown bytes)',
 u'redirected': False,
 u'status': 200,
 u'url': u'http://localhost:8983/solr/admin/cores'}

How do you like the response, @geerlingguy?
How would {{ item }} be found in {{ solr_cores_current.content }}, which is in the next task?

Update

I've taken a closer look at the actual error message and i thought there's something wrong with the conditionals in cores.yml.
And i've come to this issue about formatting substring conditionals.
So i decided to remove '{{ and }}' around variables and the error has disappeared.
Also i've added additional solr core, so my new playbook contains next variables:

vars:
  solr_version: 5.4.1
  solr_cores:
    - collection1
    - cv_dev

Furthermore, i'll apply some info, provided by -vvv parameter of ansible-playbook:

TASK [geerlingguy.solr : Ensure Solr conf directories exist.] ******************
task path: /root/solr_ansible/geerlingguy.solr/tasks/cores.yml:13
skipping: [localhost] => (item=collection1)  => {
    "changed": false, 
    "item": "collection1", 
    "skip_reason": "Conditional check failed", 
    "skipped": true
}
Using module file /usr/lib/python2.7/dist-packages/ansible/modules/core/files/file.py
<127.0.0.1> ESTABLISH LOCAL CONNECTION FOR USER: root
<127.0.0.1> EXEC /bin/sh -c 'echo ~ && sleep 0'
<127.0.0.1> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /root/.ansible/tmp/ansible-tmp-1491311305.66-128931807342653 `" && echo ansible-tmp-1491311305.66-128931807342653="` echo /root/.ansible/tmp/ansible-tmp-1491311305.66-128931807342653 `" ) && sleep 0'
<127.0.0.1> PUT /tmp/tmpGqeEQI TO /root/.ansible/tmp/ansible-tmp-1491311305.66-128931807342653/file.py
<127.0.0.1> EXEC /bin/sh -c 'chmod u+x /root/.ansible/tmp/ansible-tmp-1491311305.66-128931807342653/ /root/.ansible/tmp/ansible-tmp-1491311305.66-128931807342653/file.py && sleep 0'
<127.0.0.1> EXEC /bin/sh -c '/usr/bin/python /root/.ansible/tmp/ansible-tmp-1491311305.66-128931807342653/file.py; rm -rf "/root/.ansible/tmp/ansible-tmp-1491311305.66-128931807342653/" > /dev/null 2>&1 && sleep 0'
changed: [localhost] => (item=cv_dev) => {
    "changed": true, 
    "diff": {
        "after": {
            "group": 1000, 
            "owner": 1000, 
            "path": "/var/solr/data/cv_dev/conf", 
            "state": "directory"
        }, 
        "before": {
            "group": 0, 
            "owner": 0, 
            "path": "/var/solr/data/cv_dev/conf", 
            "state": "absent"
        }
    }, 
    "gid": 1000, 
    "group": "solr", 
    "invocation": {
        "module_args": {
            "backup": null, 
            "content": null, 
            "delimiter": null, 
            "diff_peek": null, 
            "directory_mode": null, 
            "follow": false, 
            "force": false, 
            "group": "solr", 
            "mode": null, 
            "original_basename": null, 
            "owner": "solr", 
            "path": "/var/solr/data/cv_dev/conf", 
            "recurse": true, 
            "regexp": null, 
            "remote_src": null, 
            "selevel": null, 
            "serole": null, 
            "setype": null, 
            "seuser": null, 
            "src": null, 
            "state": "directory", 
            "unsafe_writes": null, 
            "validate": null
        }, 
        "module_name": "file"
    }, 
    "item": "cv_dev", 
    "mode": "0755", 
    "owner": "solr", 
    "path": "/var/solr/data/cv_dev/conf", 
    "size": 4096, 
    "state": "directory", 
    "uid": 1000
}

Please, let me know your thoughts about the subject.

[geerlingguy]

@Sardis93 - When you ran with:

vars:
  solr_version: 5.4.1
  solr_cores:
    - collection1
    - cv_dev

Did the cv_dev core get created successfully? Also, what version of Ansible are you running?

[Sardis93]

Yep, both of them were created successfully. Actually, i've created collection1 earlier, so script was ran only for second core.

Ansible 2.2.2.0

[geerlingguy]

Thanks to @Sardis93, I think this issue is fixed in 3.5.3—I'll also be updating Drupal VM's master branch to have the latest version as well in a few minutes.