Solr 9, collections via configuration

[mkalkbrenner]

This PR raises the Solr version to 9.6. Older versions can still be used by editing the docker-compose file.

In addition I added a feature that allow the management of "cores" via configuration. So this is similar to the older and still existing other Solr integrations for ddev. By copying a configset into .ddev/solr/configsets/ it will be uploaded to Solr and a collection with the same name will be created. This way, lagacy applications that only provide such a Solr config and expect a Solr standalone core should be able to connect like the did before.

[rfay]

FYI, the best way to use older version is with a docker-compose.solr_extra.yaml file, rather than editing. That way newer versions of the add-on can still be gotten with ddev get

[rfay]

I imagine this should be a new major version when released?

[mkalkbrenner]

I imagine this should be a new major version when released?

@rfay yes, makes sense.

tests are passing now. so it would be great if you review the PR in case I missed something new as I didn't contribute for some time ;-)

What do you think of the additional feature for configsets? Might some other solr ddev packages be obsolete now?

[mkalkbrenner]

BTW I committed the official techproducts example configset. Previously we only had it as zip for tests. I wonder if we could leverage post_install_actions to copy it from the container instead of committing it. I got the files like this: docker cp ddev-${DDEV_PROJECT}-solr:/opt/solr/server/solr/configsets/sample_techproducts_configs .ddev/solr/configsets/techproducts

[rfay]

I wonder if we could leverage post_install_actions to copy it from the container

Yes, I don't know why you couldn't do exactly what you did. However, what you already did is simpler and perhaps more stable.

[mkalkbrenner]

It seems like the tests could get more significant instead of less significant

I didn't remove any test. But parts of the test now "moved" and became a part of the commands in docker-compose. And I split some which are specific for the release version.

[mkalkbrenner]

@rfay I spent some time on experimenting with the zookeeper version that is embedded in Solr. It is not suited for production use as it can't replicate itself. But for our use-case, having only a single Solr node in the Solr Cloud, it is sufficient. So it simplifies our stack if I remove bitnami's zookeeper :-) I also added the solr-zkcommand to ease the usage of solr zk from the host. So you could simply use ddev solr-zk instead of ddev solr zk -z localhost:9983.

[ddltest]

Simplifying sounds great!

[mkalkbrenner]

@rfay I think, I addressed everything. I also upgraded a ddev environment with 4 collections and >100K documents to this version. It worked perfectly well, including all automation scripts.

[rfay]

Yay, thanks!