janhoy commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6472070152
@danielmeint
I ran a local end-to-end test of this branch on Docker Desktop (k8s 1.36.1),
going from operator v0.9.1 all the way to Solr 10:
1. Installed CRDs v0.9.1, then operator v0.9.1 (CRDs managed separately,
operator installed with `--skip-crds`).
2. Created a SolrCloud on Solr 9.7.0, added a collection, indexed 10 docs,
verified queries.
3. Upgraded the CRDs to v0.10.0, leaving the operator and the running
cluster alone.
4. Upgraded the operator to v0.10.0 from this branch, leaving the SolrCloud
on Solr 9.7.0.
5. Upgraded Solr 9.7.0 → 9.11.0, verified queries.
6. Upgraded Solr 9.11.0 → 10.1.0, verified queries.
Doc counts and query results were identical at every step, and Lucene 10.4
opened the index written by Solr 9.11 without complaint. It was a 1-node
cluster and 1-shard collection. Two things are worth flagging.
**Every SolrCloud restarts on the operator upgrade, including ones staying
on 9.x.** The upgrade notes currently say that SolrClouds on Solr 8.11 or 9.x
"are not changed by this upgrade, so their pods are not restarted". That holds
for the Solr 10 specific changes, which are correctly gated on the major
version, but three other v0.10.0 changes alter the pod template of every
SolrCloud: the new `solr.apache.org/storageMinimumSize` annotation, the removal
of the `postStart` lifecycle hook, and the new `SOLR_TOOL_OPTS` env var on the
ZooKeeper setup initContainer. My 9.7.0 cluster got a new pod UID and
StatefulSet generation 1 → 2 right after the operator upgrade (step 4 above,
with no Solr version change). It is a managed rolling restart (cluster op lock,
`maxPodsUnavailable` respected), so it is well-behaved, but operators should
plan for it rather than expect a no-op.
**Custom `log4j2.xml` files break silently on Solr 10.** Solr 10 renamed the
`solr.log.dir` sysprop to `solr.logs.dir`. If you supply your own `log4j2.xml`
through `providedConfigMap`, appenders referencing `${sys:solr.log.dir}` fail
to initialise, and Solr starts fine with console logging but writes no log
files at all — no `solr.log`, no `solr_slow_requests.log`, just a burst of
log4j `main ERROR` lines at startup that are easy to miss.
`${env:SOLR_LOGS_DIR}` works on both Solr 9 and Solr 10 images, so it needs no
change across the upgrade. The notes cover custom `solr.xml` but not
`log4j2.xml`, which travels through the same mechanism.
I will push a commit with re-wording of both these upgrade-notes
Smaller observations:
- Upgrading the CRDs alone (step 3) is genuinely a no-op: pod UID, start
time, StatefulSet generation and revision were all byte-identical afterwards,
and a `v0.9.1`-created SolrCloud validates against the v0.10.0 schema in a
server-side dry-run. I diffed the full OpenAPI property set of all three CRDs
between v0.9.1 and v0.10.0 — zero properties removed, 190 added, all of them
upstream Kubernetes API surface from a newer controller-gen.
- Unrelated to this branch, but it bit me during the test: with Helm 4
(server-side apply), `helm upgrade` of a chart that manages a SolrCloud fails
with a field ownership conflict on
`.spec.customSolrKubeOptions.podOptions.initContainers`, because the operator
writes its computed defaults back into the CR spec with a plain `Update` and
becomes the exclusive field manager. `--force-conflicts` works around it. I
filed #872 for it.
- Also pre-existing and unrelated: the `preStop` hook `solr stop -p <port>`
can never succeed in the official image, since `bin/solr stop` needs
`$SOLR_PID_DIR/solr-<port>.pid` and foreground mode writes no PID file. Every
pod deletion emits a `FailedPreStopHook` warning. I filed #871 for this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
