Apache Solr collection cannot be loaded

[xaviemirmon]

Hi Guys,

I've been banging my head against this one for few days and cannot seem to get it working. I am trying to install VLAD with Apache Solr for the Apache Solr module implementation rather than Search API. To do that I have added to my vlad_settings.yml:

solr_install: true

drupal_solr_package: "apachesolr"

I've re-provisioned my machine multiple times trying to get it running but every time I am getting the following error on the Solr page:

My box is being provisioned with default settings except for the following constraints (which probably irrelevant):

memcached_install: true

redis_install: true

sendmail_install: true

solr_install: true

vm_cpus: 2

vm_memory: 3072

mysql_max_allowed_packet: 256M

Any thoughts are greatly appreciated.

Thanks!

[philipnorton42]

I think this is closely related to issue #212, if not just a symptom of the same issue.

[xaviemirmon]

I had a look at that issue and seems a bit different because my Ansible log isn't showing any failures copying. Let me just grab my versions and them to this ticket.

[xaviemirmon]

Virtual Box: 4.3.26r98988 Vagrant: 1.7.2 Ansible: 1.9.0.1 configured module search path = None

Ahh they are the same versions as in issue #212. I wonder if there is something different in a newer version of Ansible 1.9 or Vagrant 1.7 causing issues with the copying process but not reporting the error for me.

[xaviemirmon]

I have managed to track this down to Ansible. After downgrading to 1.8.4 it's fixed my issue. So there must be something in the new 1.9.x version that is causing these issues.

[philipnorton42]

Brilliant! Thanks for the info. That will definitely help us track down what was introduced to cause this.

[philipnorton42]

Just a quick update. I've managed to replicate this, which means that something is causing the problem in ansible 1.9.x. I'm now working to find out what it is, but I've not had a lot of time this week.

[dixhuit]

copy behavior did change in Ansible 1.9: https://github.com/ansible/ansible/issues/10576

I've yet to check if this is specifically what's effecting Vlad here though.

[philipnorton42]

Thanks Dan, my first thought was that copy was at fault here so it's definitely worth investigation.

[dixhuit]

All instances of copy within the solr role appear to be using absolute paths in the dest property so https://github.com/ansible/ansible/issues/10576 might be a red herring:

Searching 3 files for "copy: "

/Volumes/Data/Projects/vlad/vlad/vlad/playbooks/roles/solr/tasks/debian_solr.yml:
   10  
   11  - name: change port of tomcat server
   12:   copy: src=tomcat/server.xml dest=/etc/tomcat6/server.xml
   13    sudo: true
   14  
   ..
   24  
   25  - name: copy the tomcat6 users file
   26:   copy: src=tomcat/tomcat-users.xml dest=/etc/tomcat6/tomcat-users.xml owner=tomcat6 group=tomcat6 mode=0644
   27    sudo: true
   28    notify:
   ..
  128  
  129  - name: copy the web.xml tomcat solr integration file
  130:   copy: src=tomcat/debian_web.xml dest=/var/lib/tomcat6/webapps/solr/WEB-INF/web.xml
  131    sudo: true
  132  
  133  - name: copy the properties file
  134:   copy: src=tomcat/log4j.properties dest=/usr/share/tomcat6/lib/log4j.properties
  135    sudo: true
  136  

/Volumes/Data/Projects/vlad/vlad/vlad/playbooks/roles/solr/tasks/redhat_solr.yml:
   10  
   11  - name: change port of tomcat server
   12:   copy: src=tomcat/server.xml dest=/etc/tomcat6/server.xml
   13    sudo: true
   14  
   ..
   24  
   25  - name: copy the tomcat6 users file
   26:   copy: src=tomcat/tomcat-users.xml dest=/etc/tomcat6/tomcat-users.xml owner=tomcat group=tomcat mode=0644
   27    sudo: true
   28    notify:
   ..
  128  
  129  - name: copy the web.xml tomcat solr integration file
  130:   copy: src=tomcat/redhat_web.xml dest=/var/lib/tomcat6/webapps/solr/WEB-INF/web.xml
  131    sudo: true
  132  
  133  - name: copy the properties file
  134:   copy: src=tomcat/log4j.properties dest=/usr/share/tomcat6/lib/log4j.properties
  135    sudo: true
  136  

8 matches across 2 files

[philipnorton42]

So I got to the bottom of this and it's now fixed in dev.

Essentially, there were a couple of tasks that altered two lines in the solrconfig.xml file that used to produce an error. The update to Ansible made one of the tasks add a random line to the bottom of the file, which caused it to be malformed. As these two lines are now fixed in current versions of the Apache Solr and Search API Solr modules I have simply removed the tasks.

So the change between versions of Ansible was in lineinfile. I'll need to keep an eye on that... I'll close this issue for now and release a new version in the next couple of days. Feel free to re-open if it doesn't fix it for you.

[dixhuit]

Any idea what the change to lineinfile was?

[philipnorton42]

I can't see what it was. I've looked at the documentation and can't see anything obvious. It seems to be reverting back to a EOF argument for the insertafter parameter though. I can see the same problem in the php variables so I'll do some playing and see what I can figure out!