Complications around readinessChecks and pod restarts about solr-operator HOT 5 CLOSED

Follow this ticket for a better status handler for Solr. https://issues.apache.org/jira/browse/SOLR-14210?filter=-3

Knowing that this will only work for certain versions of Solr (8.5+), we will likely need to have a parameter to allow for disabling of this check for unsupported Solr versions.

from solr-operator.

What happens with e.g. a version upgrade if there is only one pod? Downtime?
Or if there are multiple pods, but a collection has replicationFactor=1 - will that collection be unavailable during upgrade? Or some magic that increases rf during upgrade?

from solr-operator.

This will be released in 8.6. The new parameter is /api/node/health?requireHealthyCores=true. On pre-8.6 versions, adding this parameter will not throw an error, but the health check will return OK even if cores are recovering.

from solr-operator.

yes, we should definitely add that by default when using the /api/node/health handler. Unfortunately that handler is only available for solr 8+, so we will likely need a parameter in the CRD that allows for a backwards compatible health check endpoint.

from solr-operator.

Also sorry for missing your previous question, I thought I had responded. Since we are using a StatefulSet, there should be downtime unfortunately. Though we could definitely add in our own magic to make that work. I think we need some architectural discussions around upgrades/rolling restarts in general.

from solr-operator.