Don't overwrite the configmap used for solr.xml

[whitleykeith]

Describe the bug
I'd like to have a custom solr.xml but everytime I try to update the configmap it just resets back to the original version. I know that this is the operator reconciling the resources back to a desired state but it also removes the ability to configure the solr.xml. This happens even if the configmap existed before the solr cluster was created.

To Reproduce
Steps to reproduce the behavior:

1. Deploy solr through the operator
2. Edit the configmap to what you want it to be
3. Watch it go back to the original state.

Expected behavior
Depends on how you all want to solve this. IMO you should be able to deploy a configmap with your solr cluster and reference it in the CRD. Similar to how you can connect to an existing ZK Cluster by passing in a connection string.

You could also solve this by passing the values present in the solr config into the yaml file and letting it be updated there (i.e. adding a "config" block for solr that would map to values in the solr xml.)

Environment (please complete the following information):
Solr 8.4.1 and 7.7.2, EKS v1.14

[HoustonPutman]

I definitely understand this. And we have recently added options for customizing Kube objects, such as the ConfigMap (#75). Right now this just means labels & annotations, but this could be extended to change the data in some way.

We could definitely add in the option for you to give your own solr-xml configMap. My concern there is that you can easily break your solrClouds at that point, as that is where we configure the ports solr uses.

Do you have defined ways in which you would like to change your solr.xml? Maybe we could template those and add them in as options in the SolrCloud CRD?

[sepulworld]

Also, a lot of Solr options can be passed in as env variables during process startup. Solr-operator supports that. Get Outlook for iOS On Wed, Feb 26, 2020 at 8:49 AM -0800, "Houston Putman" <[email protected]> wrote: I definitely understand this. And we have recently added options for customizing Kube objects, such as the ConfigMap (#75). Right now this just means labels & annotations, but this could be extended to change the data in some way. We could definitely add in the option for you to give your own solr-xml configMap. My concern there is that you can easily break your solrClouds at that point, as that is where we configure the ports solr uses. Do you have defined ways in which you would like to change your solr.xml? Maybe we could template those and add them in as options in the SolrCloud CRD? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[janhoy]

Yes, a lot of Solr options can now be made with ENV variables, "the docker way". So perhaps providing even more SOLR_FOO variables to control various settings makes sense. Problems may arise once you need to add, say, your custom ShardHandlerFactory.

Since Solr supports loading solr.xml from zookeeper, and since Solr will look in ZK before it looks in $SOLR_HOME, there is actually a workaround by uploading your custom solr.xml to ZK. But that must be done before starting the nodes, so perhaps the Operator could make it easy to provide your custom solr.xml that will be uploaded to zk. Of course, that solr.xml would need to preserve all the <str name="host">${host:}</str> and other default tags for the rest of Solr to work.