Lando destroy only way to be able to restart SOLR and get new versions of configuration files

[drupov]

Tell us about your setup

lando v3.0.0-rc.14
Ubuntu 18.10

Tell us about your .lando.yml

name: solr-test
services:
  solrsearch:
    type: solr:6.6
    core: solr
    portforward: 8983
    config:
      dir: ./files

Tell us generally about your bug

The files directory contains a bunch of configuration files for solr. Often these files have to be updated, in order to tune solr. After an update of such a file a restart of solr is needed.

Here is also the problem: only by running lando destroy I am able to get the updated version of the files.

lando rebuild and lando restartare not enough. To make things more interesting I was also not able to make these updates by deleting containers and even images directly through docker, docker rm [container_id] and docker rmi [image_id].

The only thing that works is lando destroy, which is not ideal, as it means having to import databases anew on big project, that takes time etc.

Anyone has a clue on what's going on here?

[drupov]

Have kind of the same thing going on with a related issue:

If I launch a very plain lando environment with Drupal 8 with environment variables overrides only:

## .lando.yml
name: test
recipe: drupal8
config:
  via: nginx
  webroot: web
tooling:
  drush:
    service: appserver
    cmd: drush --root=/app/web
env_file:
  - .env

## .env
DB_USER=test
DB_PASSWORD=test

I am able to override the default database and username for that "drupal8"-recipe, which would be both "drupal8" (overridden by "test" with that).

If I decide later to not use the .env-file (so remove the file and remove the env_file-key in .lando.yml the only way to make the environment understand that is lando destroy. Not possible via lando restart, lando rebuild or by destroying containers and removing images via docker rm and docker rmi? Where is that data stored/cached? Can I purge it, without going the "destroy" route?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.

[pirog]

unstale

[hussainweb]

I spent about 6+ hours trying to resolve SOLR config issues, of which 3 hours were due to this issue. I couldn't really destroy and that set me to debug this issue.

First, workaround:

If you don't want to destroy, then you can just ssh into the solr instance and delete the core directory. For example, in my case I had to run

$ lando ssh -s index # My service name is index
/app$ rm -rf /opt/solr/server/solr/mycores/d8core

This removes all indexed data of course, but it is slightly better than having lando destroy destroy all containers.

Now, the fix:

The problem is in builder.js. The entire core directory including the conf directory is mounted to the volume. I am not really sure why. Eventually, the precreate-solr script in the solr image is called. This script only copies the conf directory if the directory doesn't exist already.

Now, I am not sure if this is a bug in the Docker image. I can see the use case of checking if the directory exists before copying the config. However, I am not sure of the use case of mounting the whole core directory instead of just the data directory.

[pirog]

@drupov the database credentials get set the first time you create those services. This is just how the underlying image sets stuff and im not sure there is a ton we can do about it beyond document it, which we've done in multiple places like
https://docs.devwithlando.io/tutorials/mysql.html#configuration
https://docs.devwithlando.io/issues/switching-dbs.html

The config issue with solr def feels much more like a legit bug so im going to try and dive into @hussainweb's great work

[pirog]

ok @hussainweb i think ive tracked this down. the core (get it?) problem here is with the default implementation. you cannot persist the cores data (eg its index) while also allowing any updates to the config files of said core to be reflected.

This is because once you try to volume mount a cores data directory (which happens first) the core-create scripts see that a core already exists so it happily moves on without actually building the core and setting its config. This is why we volume mount the entire mycores directory.

However, and as you note this prevents config changes from propagating unless you destroy the entire container since the config is now persistent mounted as well. This is definitely a pretty shitty tradeoff but i think we can get around it by tweaking our own solr start up script a bit. Which is what i've done to address the issue

See: 39ba766

[milkovsky]

$ lando ssh -s index # My service name is index
/app$ rm -rf /opt/solr/server/solr/mycores/d8core

This did not remove the solr core entirely for me. Another workaround:

lando ssh -s index
solr delete -c d8core