Update solr configset to match latest search_api_solr release in Drupal solr images

[richardgaunt]

There has been a release in late september for search_api_solr:

https://www.drupal.org/project/search_api_solr/releases/4.3.0

When updating to this module we need to manually update the configset files as they are mapped to the older release 4.1.1. See: https://github.com/uselagoon/lagoon-images/tree/main/images/solr-drupal/drupal-4.1.1-solr-7.x-0/conf

Could the solr containers be updated to use the updated configset files for 4.3.0?

[tobybellwood]

We will generally avoid updating the Solr version in these base images because of the risk of introducing breaking changes to unaware downstream users who just want to plug and play. This 4.3.0 release is a particularly involved one - it's not a simple upgrade.

We would always recommend that if you want customisability that you should inherit these images and provide your own config.

We've got a couple of options available:

Downloading the solr-conf version you want (and potentially adding any customisations)
https://github.com/lagoon-examples/drupal9-solr/blob/solr8/lagoon/solr.dockerfile

Or copying the config-set straight out of the version of the module installed in your cli image
https://github.com/lagoon-examples/drupal9-full/blob/main/lagoon/solr.dockerfile

We're also trying to get a Solr9 release together, that will (have to be 😉) built on the 4.3.0 release

[AlexSkrypnyk]

Could we please have the docs updated at https://docs.lagoon.sh/drupal/services/solr/ to mention that the schema shipped with images is tied to the search_api_solr module version.

Currently, it reads

For Solr 5.5, 6.6 and 7.7, we ship the default schema files provided by the [search_api_solr](https://www.drupal.org/project/search_api_solr) Drupal module.

which implies that the default schema is "all you need" when using images. But in reality, one has to update the schema config files with every version update of search_api_solr module.

It would be great to also have a section about upgrading configs, since it is not a straightforward image replace - we had to clear the index, rebuild the pod, and re-run the index (which took us many hours to figure out).

[tobybellwood]

Docs contributions are always welcome!

We don't use the images ourselves, so any guidance from the community on how they're utilised is always gratefully received. https://docs.lagoon.sh/contributing-to-lagoon/documentation/

[richardgaunt]

At the moment, the way solr-drupal is setup, you cannot update the module and configuration that is provided with the module.

The script used to create the core precreate does not overwrite existing config when it is called, so when the old 4.1.1 configuration is copied in place, a downstream user would need to delete out that directory, and then add recreate the core which is not obvious ie took a fair amount of debugging when we were trying to update our module.

Might be better to stop tying solr-drupal to a module version. Perhaps adopting the strategy used in GovCMS to provide the config files from the module - which should be a reasonable set of defaults and maybe add a README that you need to update your container / delete the core to upgrade a solr version via module upgrade:

https://github.com/govCMS/lagoon/blob/3.x-develop/.docker/Dockerfile.solr

[tobybellwood]

One thing we've learnt from solr is that everybody does it a different way - which makes it really hard to document!

The work I've been doing on the solr9 branch doesn't pin the config to an old module - but instead loads the jump-start from the 4.x upstream branch. Still not perfect, but will work for anyone who isn't building their own dockerfile.

In the example we provide (and where GovCMS got it from) we do indeed sideload the module config straight from the cli pod (and even provide an example of running two cores) - https://github.com/lagoon-examples/drupal-solr/blob/main/lagoon/solr.dockerfile