You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "danielmeint (via GitHub)" <gi...@apache.org> on 2026/04/27 12:04:27 UTC
[PR] Add Solr 10 compatibility support [solr-operator]
danielmeint opened a new pull request, #827:
URL: https://github.com/apache/solr-operator/pull/827
## Summary
Adds version-conditional support for Solr 10 to the operator while preserving full backwards compatibility with Solr 9.x. With this change, all major operator-managed flows (cluster bootstrap, scaling, security, TLS, backups, ingress, rolling upgrades) work against a Solr 10.0 image.
This builds on the partial fix proposed in #826 and addresses #821 (\"Solr 10.0 - No tests pass\"). The Prometheus exporter is intentionally out of scope — `solr-exporter` was removed from the Solr distribution in 10, see #820.
## What changed
Version detection is centralized on the `SolrCloud` type:
- `(*SolrCloud).IsSolr10OrLater()` — parses the major version from the configured image tag, handles a nil `SolrImage`, and treats unparseable tags (`latest`, `nightly`, custom) as pre-10 for backwards compatibility.
- A package-level `IsSolr10OrLater(imageTag string)` is also exported for the few call sites that only have a raw image string.
Areas updated for Solr 10:
| Area | Change |
|---|---|
| `solr.xml` | New `DefaultSolrXMLForSolr10` template — drops `genericCoreNodeNames`, `hostContext`, `allowPaths`, `metricsEnabled`, switches `host` element to `${solr.host.advertise:}` |
| Host advertise | Sets `SOLR_HOST_ADVERTISE` env var (replaces the deprecated `host` sysprop) |
| Modules | Sets `SOLR_MODULES` env var; skips `/opt/solr/contrib/<module>/lib` and `/opt/solr/dist` paths in `sharedLib` (these directories no longer exist in 10) |
| `hostPort` sysprop | Skipped on Solr 10 (no longer required) |
| TLS cluster prop | `setUrlSchemeClusterPropCmd` uses `solr zk cp` instead of the removed `cloud-scripts/zkcli.sh` |
| Secure probes | `useSecureProbe` uses `solr api --solr-url …` instead of the removed `-get` flag |
| E2E helpers | `callSolrApiInPod` uses `--solr-url` and the native `--credentials user:pass` flag (Solr 10 no longer honors `-Dbasicauth=…` via `JAVA_TOOL_OPTIONS`) |
## Test plan
- [x] Unit tests for the version parser (`SolrMajorVersion`, `IsSolr10OrLater` — including unparseable / nil-image cases)
- [x] Unit tests for both `solr.xml` templates (Solr 9 and Solr 10)
- [x] Unit tests for both branches of `useSecureProbe`
- [x] E2E against Solr 10.0.0:
- [x] Basic
- [x] Scale Down / Scale Up with replica migration
- [x] Security JSON — Provided + Bootstrapped
- [x] TLS — Secrets (No Client TLS, Client TLS, ClientAuth Need/Want, CheckPeerName, VerifyClientHostname)
- [x] TLS — Mounted Dir (ClientAuth Want)
- [x] Backups — Local Directory (Recurring + Single)
- [x] Ingress (addressability change)
- [x] Rolling Upgrades (Managed Update)
- [ ] Prometheus Exporter — fails as expected, exporter removed in Solr 10 (#820)
- [x] E2E regression baseline against Solr 9.8.0 — Basic suite passes
## Notes
- Marked draft — happy to split into smaller commits, rework the API surface, or scope down based on review feedback.
- One open cosmetic item: Solr 10 logs a `\"deprecated system property host\"` warning at startup. After investigation this appears to be a Solr-side false positive (`bin/solr` in 10 doesn't translate `SOLR_HOST` to `-Dhost`, and Solr 10's own default `solr.xml` ships with the same `<str name=\"host\">${solr.host.advertise:}</str>` element). Removing `SOLR_HOST` from the pod spec doesn't silence it. Left as-is; happy to file upstream in Solr if that's preferred.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "Copilot (via GitHub) via issues" <is...@solr.apache.org>.
Copilot commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4455674977
##########
controllers/solrprometheusexporter_controller.go:
##########
@@ -92,6 +92,27 @@ func (r *SolrPrometheusExporterReconciler) Reconcile(ctx context.Context, req ct
requeueOrNot := ctrl.Result{}
+ // Get the ZkConnectionString to connect to
+ solrConnectionInfo := util.SolrConnectionInfo{}
+ var solrCloudImage *solrv1beta1.ContainerImage
+ if solrConnectionInfo, solrCloudImage, err = getSolrConnectionInfo(ctx, r, prometheusExporter); err != nil {
+ return requeueOrNot, err
+ }
+
+ // Solr 10 removed the Prometheus exporter, and Solr 10's metrics API only serves the Prometheus format,
+ // so neither a Solr 10+ exporter image nor a referenced Solr 10+ SolrCloud can work.
+ // Don't create or update any resources for such an exporter. An existing Deployment is left alone, but marked not ready.
+ if msg := unsupportedExporterSolrVersion(prometheusExporter.Spec.Image, solrCloudImage); msg != "" {
+ logger.Error(nil, msg)
+ r.Recorder.Event(prometheusExporter, corev1.EventTypeWarning, "UnsupportedSolrVersion", msg)
+ if prometheusExporter.Status.Ready {
+ originalPrometheusExporter := prometheusExporter.DeepCopy()
+ prometheusExporter.Status.Ready = false
+ return reconcile.Result{}, r.Status().Patch(ctx, prometheusExporter, client.MergeFrom(originalPrometheusExporter))
+ }
+ return reconcile.Result{}, nil
Review Comment:
A rejected exporter referencing a SolrCloud in another namespace will not resume reconciliation when that cloud changes to a supported version: this return schedules no retry, and `indexAndWatchForSolrClouds` only searches the cloud's own namespace. The same watch limitation can leave an existing cross-namespace exporter marked ready after its cloud upgrades to Solr 10. Index references by the cloud's effective namespace and name, query exporters across namespaces, and test both transitions.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "danielmeint (via GitHub)" <gi...@apache.org>.
danielmeint commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6502972796
> It would be beneficial if the Operator could log a fat ERROR if attempting to start a SolrPrometheusExporter based on a Solr10.x image. Log and abort, instead of failing with some command not found error msg (or whatever it does now?)
> we can add an event to the SolrPrometheusExporter resource that says it's not supported
done, the operator now doesn't reconcile a `SolrPrometheusExporter` if a Solr 10 image is used, but it emits an `UnsupportedSolrVersion` warning event and also logs an error
> a wild idea could be to let the Operator discover the version by kicking a k8s Job that does nothing more than print the version
Wild idea indeed :) personally, I'd be skeptical the additional complexity makes anyone's life easier 😅 extra pod, pull secret, permission, ...
A slightly "lighter" alternative could be to read the `org.opencontainers.image.version` OCI label which the official images carry ([reference](https://github.com/apache/solr-docker/blob/884b2e6692174ea09cdb5183b8dd585760b5e9fb/10.0/Dockerfile#L86)) and images built `FROM solr` inherit. This could be read via [go-containerregistry](https://github.com/google/go-containerregistry) and cached by digest 🤔 It would still require registry access and probably has other caveats, so I'm not convinced either and I'd stick with tag parsing for this PR at least
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "HoustonPutman (via GitHub)" <gi...@apache.org>.
HoustonPutman commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6454676212
So we have events now in the project, so we can add an event to the `SolrPrometheusExporter` resource that says its not supported, much better than logging IMO
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "danielmeint (via GitHub) via issues" <is...@solr.apache.org>.
danielmeint commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4456450445
##########
controllers/solrprometheusexporter_controller.go:
##########
@@ -92,6 +92,27 @@ func (r *SolrPrometheusExporterReconciler) Reconcile(ctx context.Context, req ct
requeueOrNot := ctrl.Result{}
+ // Get the ZkConnectionString to connect to
+ solrConnectionInfo := util.SolrConnectionInfo{}
+ var solrCloudImage *solrv1beta1.ContainerImage
+ if solrConnectionInfo, solrCloudImage, err = getSolrConnectionInfo(ctx, r, prometheusExporter); err != nil {
+ return requeueOrNot, err
+ }
+
+ // Solr 10 removed the Prometheus exporter, and Solr 10's metrics API only serves the Prometheus format,
+ // so neither a Solr 10+ exporter image nor a referenced Solr 10+ SolrCloud can work.
+ // Don't create or update any resources for such an exporter. An existing Deployment is left alone, but marked not ready.
+ if msg := unsupportedExporterSolrVersion(prometheusExporter.Spec.Image, solrCloudImage); msg != "" {
+ logger.Error(nil, msg)
+ r.Recorder.Event(prometheusExporter, corev1.EventTypeWarning, "UnsupportedSolrVersion", msg)
+ if prometheusExporter.Status.Ready {
+ originalPrometheusExporter := prometheusExporter.DeepCopy()
+ prometheusExporter.Status.Ready = false
+ return reconcile.Result{}, r.Status().Patch(ctx, prometheusExporter, client.MergeFrom(originalPrometheusExporter))
+ }
+ return reconcile.Result{}, nil
Review Comment:
Looks like a valid finding, but pre-existing and not caused by the changes in this PR
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "aymen-guellala (via GitHub) via issues" <is...@solr.apache.org>.
aymen-guellala commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6536163919
Hi everyone,
We are currently preparing our infrastructure for a migration from Sitecore 10.4.1 to Sitecore 10.5.
Our current stack uses SolrCloud 9.8 managed by Solr Operator 0.9.1. Since Sitecore 10.5 upgrades its requirements to Solr 10 (specifically requiring SolrCloud mode), we attempted to test Solr 10 with our existing Solr Operator 0.9.1 deployment, but it is not supported and failed to run.
I noticed in a previous discussion that the team is waiting for the release of Solr 10.1 before delivering a new version of the Solr Operator that natively supports Solr 10.x.
Does the team have an estimated time of arrival (ETA) for this new Solr Operator release?
Thank you very much for your time and hard work on this project!
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6404073173
> if we already require declaring the major version in the CRD then IMHO the operator should accept any image tag name
This PR proposed adding such a major version declaration to the CRD. But we never had one. So far the operator has been treating all clusters the same, using same APIs and same commands. But with Solr 10 changes are so big taht we need separate handling. Requiring that the tag starts with the major version is then the least intrusive.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub) via issues" <is...@solr.apache.org>.
janhoy commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4466561738
##########
controllers/solrprometheusexporter_controller.go:
##########
@@ -92,6 +92,27 @@ func (r *SolrPrometheusExporterReconciler) Reconcile(ctx context.Context, req ct
requeueOrNot := ctrl.Result{}
+ // Get the ZkConnectionString to connect to
+ solrConnectionInfo := util.SolrConnectionInfo{}
+ var solrCloudImage *solrv1beta1.ContainerImage
+ if solrConnectionInfo, solrCloudImage, err = getSolrConnectionInfo(ctx, r, prometheusExporter); err != nil {
+ return requeueOrNot, err
+ }
+
+ // Solr 10 removed the Prometheus exporter, and Solr 10's metrics API only serves the Prometheus format,
+ // so neither a Solr 10+ exporter image nor a referenced Solr 10+ SolrCloud can work.
+ // Don't create or update any resources for such an exporter. An existing Deployment is left alone, but marked not ready.
+ if msg := unsupportedExporterSolrVersion(prometheusExporter.Spec.Image, solrCloudImage); msg != "" {
+ logger.Error(nil, msg)
+ r.Recorder.Event(prometheusExporter, corev1.EventTypeWarning, "UnsupportedSolrVersion", msg)
+ if prometheusExporter.Status.Ready {
+ originalPrometheusExporter := prometheusExporter.DeepCopy()
+ prometheusExporter.Status.Ready = false
+ return reconcile.Result{}, r.Status().Patch(ctx, prometheusExporter, client.MergeFrom(originalPrometheusExporter))
+ }
+ return reconcile.Result{}, nil
Review Comment:
Spun off in #879
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "ArbitraryCritter (via GitHub)" <gi...@apache.org>.
ArbitraryCritter commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-4368872949
This looks great, I'll see if I can give it a whirl in our test cluster.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "HoustonPutman (via GitHub)" <gi...@apache.org>.
HoustonPutman commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6323880421
> > introducing a breaking change does not feel right, i was able to get the current operator to work against solr 10 just by pointing it to a valid solr.xml
>
> I agree on this point. Solr Operator should know how to detect a cluster version based on current config. Proposal:
>
> If the `image.tag` prefix complies with normal semVer, e.g. `10.1.0`, `9.11.0`, `10.1.0-SNAPSHOT`, `10.2.0-my-company-custom-overlay-9.3`, then deduce major version from imageTag. If the tag does not comply, fall back to parsing an optional `solrMajorVersion´, if that is not set, log error and abort.
Yeah, I like this. Though I would add, that maybe there are non-semver-compliant `.a.b.c.d.e` versions, that we should be ok with too.
But I actually want to stay away from solrMajorVersion entirely, I really really really hate that we would need that ever. For these bad edge cases, I can accept parsing tags. But that will go away soon, and will happen very rarely hopefully.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "danielmeint (via GitHub)" <gi...@apache.org>.
danielmeint commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4414953745
##########
controllers/solrcloud_controller.go:
##########
Review Comment:
There's now an `InvalidConfigMap` warning event emitted in case `hostContext` or `genericCoreNodeNames` are detected. See if this makes sense to you 🙂
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "danielmeint (via GitHub)" <gi...@apache.org>.
danielmeint commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4414905917
##########
docs/modules/upgrade-notes/pages/upgrade-notes.adoc:
##########
@@ -136,6 +137,35 @@ _Note that the Helm chart version does not contain a `v` prefix, which the downl
=== v0.10.0
+* *Solr 10 support, and Solr image tags must start with the Solr version*
++
+The Solr Operator now supports Solr 10.
+Solr 10 needs a different `solr.xml`, different env vars and different `bin/solr` commands than Solr 9, so the operator reads the Solr version from `spec.solrImage.tag`.
+The tag must therefore start with the Solr version, e.g. `9.10.0`, `10.0.0`, `9.10`, `8.11`, `10`, `9.10.0-slim`, `10.0.0-my-custom-build` or `10.0.0@sha256:<digest>`.
+Tags without a version, such as `latest` or `slim`, and custom tags that don't start with the Solr version, are not accepted.
+The operator does not reconcile a SolrCloud with such a tag, or with an unsupported Solr major version; it emits an `UnsupportedSolrVersion` Warning event instead.
+*Before upgrading the operator*, check the image tags of your SolrClouds (including the `image.tag` value of the `solr` Helm chart) and change them where needed.
+SolrClouds that never set a tag got the operator's default tag at the time they were created (e.g. `8.11`), which is accepted.
+SolrClouds running Solr 8.11 or 9.x with an accepted tag are not changed by this upgrade, so their pods are not restarted.
+Changing a tag, e.g. from `latest` to `9.10.0`, changes the pod template and therefore restarts all Solr pods, even if the new tag points to the same image.
+If you pass `-Dsolr.allowPaths=...` via `solrOpts`, use `-Dsolr.security.allow.paths=...` when moving to Solr 10, which doesn't read the old camelCase name anymore.
Review Comment:
added a line below; `SOLR_ALLOW_PATHS` is only read in v 9.6+ I found
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "danielmeint (via GitHub)" <gi...@apache.org>.
danielmeint commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6320098602
Thanks for the sync, @janhoy
> Do you agree with the version parsing and ready to do that change?
Yes, sounds good and happy to do that. Regarding precedence though, I'd personally lean the other way, i.e., if `solrMajorVersion` is set explicitly, I'd use that first and parse the tag only if unset. At least for us (have been using calendar versioning like `2026.10.1` before), this would be clearer.
What do you think?
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6314957997
> introducing a breaking change does not feel right, i was able to get the current operator to work against solr 10 just by pointing it to a valid solr.xml
I agree on this point. Solr Operator should know how to detect a cluster version based on current config. Proposal:
If the `image.tag` prefix complies with normal semVer, e.g. `10.1.0`, `9.11.0`, `10.1.0-SNAPSHOT`, `10.2.0-my-company-custom-overlay-9.3`, then deduce major version from imageTag. If the tag does not comply, fall back to parsing an optional `solrMajorVersion´, if that is not set, log error and abort.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "sigram (via GitHub)" <gi...@apache.org>.
sigram commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6402055076
I'm late to the discussion so maybe I'm missing the point .. but aren't we overprotective here? if we already require declaring the major version in the CRD then IMHO the operator should accept any image tag name, assuming the user knows the best.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub) via issues" <is...@solr.apache.org>.
janhoy commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4455400874
##########
api/v1beta1/solrcloud_types.go:
##########
@@ -1327,6 +1328,49 @@ func (zkInfo ZookeeperConnectionInfo) ZkConnectionString() string {
return zkInfo.InternalConnectionString + zkInfo.ChRoot
}
+// solrImageTagVersionRegex matches Solr image tags, which must start with the Solr version, "<major>[.<minor>[.<patch>...]]".
+// Anything after the version must start with neither a digit nor a dot,
+// e.g. "10.0.0", "10.1.0-SNAPSHOT", "10.0.0.1", "10.0.0@sha256:...", "9.10-slim" or "8.11".
+// Short versions are accepted because released Solr Operator versions defaulted to tags such as "8.11",
+// and they cannot change their major version.
+var solrImageTagVersionRegex = regexp.MustCompile(`^(?P<major>\d+)(?:\.\d+)*(?:[^\d.].*)?$`)
+
+const (
+ // The range of Solr major versions that the Solr Operator supports.
+ MinSupportedSolrMajorVersion = 8
Review Comment:
Filed #878 for lifting the solr version floor and assigned it to the v1.0.0 milestone
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "coolstim (via GitHub)" <gi...@apache.org>.
coolstim commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-4477137016
how does this compare to https://github.com/apache/solr-operator/pull/826
introducing a breaking change does not feel right, i was able to get the current operator to work against solr 10 just by pointing it to a valid solr.xml
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4371387919
##########
docs/modules/upgrade-notes/pages/upgrade-notes.adoc:
##########
@@ -136,6 +137,35 @@ _Note that the Helm chart version does not contain a `v` prefix, which the downl
=== v0.10.0
+* *Solr 10 support, and Solr image tags must start with the Solr version*
Review Comment:
Should we use some `====` subheaders in here, for better structure. Also, perhaps some bullets can merge into one?
##########
controllers/solrprometheusexporter_controller_test.go:
##########
@@ -342,7 +342,7 @@ var _ = FDescribe("SolrPrometheusExporter controller - General", func() {
},
Spec: solrv1beta1.SolrCloudSpec{
SolrImage: &solrv1beta1.ContainerImage{
- Tag: "should-be-the-same",
+ Tag: "9.10.0-should-be-the-same",
Review Comment:
I understand why this change was done in the test. But now when bumping the default solr version to e.g. 9.11.0 and later, there are now three more strings to update by hand.
Can you instead use e.g. the variable for Default Solr Version here, or just "9-should-be-the-same", or something that is lower maintenance?
##########
controllers/util/solr_security_util.go:
##########
@@ -497,14 +497,22 @@ func BasicAuthEnvVars(secretName string) []corev1.EnvVar {
func useSecureProbe(solrCloud *solr.SolrCloud, probe *corev1.Probe, mountPath string) {
// mount the secret in a file so it gets updated; env vars do not see:
// https://kubernetes.io/docs/concepts/configuration/secret/#environment-variables-are-not-updated-after-a-secret-update
+ isSolr10 := solrCloud.IsSolr10OrLater()
javaToolOptions := make([]string, 0)
+ credentialsArg := ""
if solrCloud.Spec.SolrSecurity != nil && solrCloud.Spec.SolrSecurity.ProbesRequireAuth && solrCloud.Spec.SolrSecurity.AuthenticationType == solr.Basic {
usernameFile := fmt.Sprintf("%s/%s", mountPath, corev1.BasicAuthUsernameKey)
passwordFile := fmt.Sprintf("%s/%s", mountPath, corev1.BasicAuthPasswordKey)
- javaToolOptions = append(javaToolOptions,
- fmt.Sprintf("-Dbasicauth=$(cat %s):$(cat %s)", usernameFile, passwordFile),
- "-Dsolr.httpclient.builder.factory=org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory",
- )
+ if isSolr10 {
Review Comment:
Instead of each class creating a `isSolr10` variable to check everywhere, it would be more generic and fewer lines to just do the version comparison logic in the conditional logic, e.g.
```go
if solrCloud.versionGte(10) { // versionLt(), versionEq()
```
##########
helm/solr/README.md:
##########
@@ -82,7 +82,7 @@ Descriptions on how to use these options can be found in the [SolrCloud document
| nameOverride | string | `""` | |
| replicas | int | `3` | The number of Solr pods to run in the Solr Cloud. If you want to use autoScaling, do not set this field. |
| image.repository | string | `"solr"` | The repository of the Solr image |
-| image.tag | string | `"9.10.0"` | The tag/version of Solr to run |
+| image.tag | string | `"9.10.0"` | The tag/version of Solr to run. Must start with the Solr version, e.g. `9.10.0`, `10.0.0-slim` or `9.10`; tags like `latest` are not supported by the Solr Operator. |
Review Comment:
Shorten this in the table, the details of the requirements are discussed elsewhere
```suggestion
| image.tag | string | `"9.10.0"` | The tag/version of Solr to run. Must start with the Solr version, e.g. `9`, `9.10` or `10.0.0-slim` |
```
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "sigram (via GitHub)" <gi...@apache.org>.
sigram commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6414951574
> Requiring that the tag starts with the major version is then the least intrusive.
Intrusive is relative ;) IMHO it's not intrusive to require that users declare explicitly what they already know in advance ("I'm going to use Solr 10") versus adding brittle and hidden magic behavior that will clash with custom image tags.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6482195196
> So we just need to document this?
Already documented in line 164- of upgrade notes in last commit. As long as it is the user's own `log4j2.xml`, we do not manage it. We COULD of course have read the content, detected `${sys:solr.log.dir}` and patched it... But ultimately Solr should have supported both variants for another major cycle..
We were **very** eager to get rid of stuff in 10.x and now we see the fruits of that with a good handfull of breaking changes. Well well.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "ArbitraryCritter (via GitHub)" <gi...@apache.org>.
ArbitraryCritter commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-4404945392
Just tested this on our 3 node staging cluster, which sees a reasonable test load, I'll keep it running in this configuration for ~a week and report any issues we may see.
Cluster state before start:
solr-operator: 0.9.1
solr: 9.10
Process:
- I first upgraded the solr-operator without any other modification (eg. helm chart and solr-operator image built from this branch).
- Upgraded the solr cluster to 10.0 based image (with some custom modules)
Findings:
There were no issues with upgrading the solr-operator itself, that just worked. Only thing to note is that the SolrMajorVersion seems to default to 9, which seems quite sane, but also slightly different from what is mentioned in the PR description, I'd expected it to complain that I needed to set a version to proceed.
As is noted in the issue, the prometheusExporter is gone from Solr 10 and upgrading with it will not work, it has to be disabled first. Failing to remove it caused the upgrade process to stall, requiring a rollback.
The SOLR_MODULES behavior seems a bit different with the new solr helm chart. We've been using a custom docker image that contains a solr module specific for own environment (used for access checks). We've been overriding the SOLR_MODULES env directly in the dockerfile. Before the solr helm chart upgrade the SOLR_MODULES variables wasn't set by the helmchart, after the upgrade it was (with the value SOLR_MODULES=s3-repository).
This was easily remedied by adding the appropriate modules to "solrOptions.SolrModules", but it does seem that something about the SolrModules env behaves a bit differently in the new solr chart.
I don't think this is a bug, it's probably more us misusing the SOLR_MODULES concept by overriding it in the Dockerfile rather than the helm chart, but perhaps a note should be added to the release that users should be sure to define the solr modules they use through the helm chart (or something similar).
All in all this seems to work as expected.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "danielmeint (via GitHub)" <gi...@apache.org>.
danielmeint commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4414463334
##########
docs/modules/upgrade-notes/pages/upgrade-notes.adoc:
##########
@@ -136,6 +137,35 @@ _Note that the Helm chart version does not contain a `v` prefix, which the downl
=== v0.10.0
+* *Solr 10 support, and Solr image tags must start with the Solr version*
++
+The Solr Operator now supports Solr 10.
+Solr 10 needs a different `solr.xml`, different env vars and different `bin/solr` commands than Solr 9, so the operator reads the Solr version from `spec.solrImage.tag`.
+The tag must therefore start with the Solr version, e.g. `9.10.0`, `10.0.0`, `9.10`, `8.11`, `10`, `9.10.0-slim`, `10.0.0-my-custom-build` or `10.0.0@sha256:<digest>`.
+Tags without a version, such as `latest` or `slim`, and custom tags that don't start with the Solr version, are not accepted.
+The operator does not reconcile a SolrCloud with such a tag, or with an unsupported Solr major version; it emits an `UnsupportedSolrVersion` Warning event instead.
+*Before upgrading the operator*, check the image tags of your SolrClouds (including the `image.tag` value of the `solr` Helm chart) and change them where needed.
+SolrClouds that never set a tag got the operator's default tag at the time they were created (e.g. `8.11`), which is accepted.
+SolrClouds running Solr 8.11 or 9.x with an accepted tag are not changed by this upgrade, so their pods are not restarted.
+Changing a tag, e.g. from `latest` to `9.10.0`, changes the pod template and therefore restarts all Solr pods, even if the new tag points to the same image.
+If you pass `-Dsolr.allowPaths=...` via `solrOpts`, use `-Dsolr.security.allow.paths=...` when moving to Solr 10, which doesn't read the old camelCase name anymore.
Review Comment:
👍 Added a sentence below, seems to only be mapped from 9.6 onward afaics
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "HoustonPutman (via GitHub)" <gi...@apache.org>.
HoustonPutman commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4381583748
##########
api/v1beta1/solrcloud_types.go:
##########
@@ -1327,6 +1328,49 @@ func (zkInfo ZookeeperConnectionInfo) ZkConnectionString() string {
return zkInfo.InternalConnectionString + zkInfo.ChRoot
}
+// solrImageTagVersionRegex matches Solr image tags, which must start with the Solr version, "<major>[.<minor>[.<patch>...]]".
+// Anything after the version must start with neither a digit nor a dot,
+// e.g. "10.0.0", "10.1.0-SNAPSHOT", "10.0.0.1", "10.0.0@sha256:...", "9.10-slim" or "8.11".
+// Short versions are accepted because released Solr Operator versions defaulted to tags such as "8.11",
+// and they cannot change their major version.
+var solrImageTagVersionRegex = regexp.MustCompile(`^(?P<major>\d+)(?:\.\d+)*(?:[^\d.].*)?$`)
+
+const (
+ // The range of Solr major versions that the Solr Operator supports.
+ MinSupportedSolrMajorVersion = 8
Review Comment:
If we make the minimum version 9, then does some of this get easier like the solr modules stuff?
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6466184307
@danielmeint @HoustonPutman WRT non-compliant image tags, like `latest`, `my-company-solr-9.11` etc, a wild idea could be to let the Operator discover the version by kicking a k8s `Job` that does nothing more than print the version. Then it can record that finding and set `isSolr10` variable accordingly
```bash
$ docker run --pull always --rm solr:latest solr version
Client version: 10.1.0
```
Note that the different CLI versions will print slightly different text for the command:
```
8.11.4
9.0.0
Solr version is: 9.11.0
Solr version is: 10.0.0
Client version: 10.1.0
Client version: 10.1.0
```
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "Tuurkevg (via GitHub)" <gi...@apache.org>.
Tuurkevg commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6211449719
Any update on 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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6365711139
> What about latest as a "special case"?
`latest` is evil, we should get used to pinning images to SHA so it is impossible to mutate :)
So basically we'll ask those tagging images for use with the operator to follow our lead and not the other way around. So here is a potential regex that we could enforce:
```go
var versionRe = regexp.MustCompile(`^(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(?:\D.*)?$`)
```
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4394671872
##########
docs/modules/upgrade-notes/pages/upgrade-notes.adoc:
##########
@@ -136,6 +137,35 @@ _Note that the Helm chart version does not contain a `v` prefix, which the downl
=== v0.10.0
+* *Solr 10 support, and Solr image tags must start with the Solr version*
++
+The Solr Operator now supports Solr 10.
+Solr 10 needs a different `solr.xml`, different env vars and different `bin/solr` commands than Solr 9, so the operator reads the Solr version from `spec.solrImage.tag`.
+The tag must therefore start with the Solr version, e.g. `9.10.0`, `10.0.0`, `9.10`, `8.11`, `10`, `9.10.0-slim`, `10.0.0-my-custom-build` or `10.0.0@sha256:<digest>`.
+Tags without a version, such as `latest` or `slim`, and custom tags that don't start with the Solr version, are not accepted.
+The operator does not reconcile a SolrCloud with such a tag, or with an unsupported Solr major version; it emits an `UnsupportedSolrVersion` Warning event instead.
+*Before upgrading the operator*, check the image tags of your SolrClouds (including the `image.tag` value of the `solr` Helm chart) and change them where needed.
+SolrClouds that never set a tag got the operator's default tag at the time they were created (e.g. `8.11`), which is accepted.
+SolrClouds running Solr 8.11 or 9.x with an accepted tag are not changed by this upgrade, so their pods are not restarted.
+Changing a tag, e.g. from `latest` to `9.10.0`, changes the pod template and therefore restarts all Solr pods, even if the new tag points to the same image.
+If you pass `-Dsolr.allowPaths=...` via `solrOpts`, use `-Dsolr.security.allow.paths=...` when moving to Solr 10, which doesn't read the old camelCase name anymore.
Review Comment:
For Solr 9 or 10 it is also possible to use `SOLR_ALLOW_PATHS` env var for the same (not for 8.x)
##########
controllers/solrcloud_controller.go:
##########
Review Comment:
We could now do a version specific check of `solr.xml` validity. E.g. Solr9 needs a `hostContext` in solr.xml, while Solr10 will fail if it has one.
##########
helm/solr-operator/Chart.yaml:
##########
@@ -138,6 +138,18 @@ annotations:
url: https://github.com/apache/solr-operator/issues/535
- name: GitHub PR
url: https://github.com/apache/solr-operator/pull/571
+ - kind: added
+ description: Support for Solr 10. See the upgrade notes before upgrading a SolrCloud to Solr 10.
+ links:
+ - name: Github Issue
+ url: https://github.com/apache/solr-operator/issues/821
+ - name: Github PR
+ url: https://github.com/apache/solr-operator/pull/827
+ - kind: changed
+ description: The SolrCloud image tag must start with the Solr version (e.g. `10.0.0`, `9.10` or `8.11`). SolrClouds with other tags, such as `latest`, are no longer reconciled; see the upgrade notes before upgrading the operator.
Review Comment:
This changelog entry probably belongs in `solr/Chart.yaml`, as that's where `image.tag` is configured.
##########
docs/modules/upgrade-notes/pages/upgrade-notes.adoc:
##########
@@ -136,6 +137,35 @@ _Note that the Helm chart version does not contain a `v` prefix, which the downl
=== v0.10.0
+* *Solr 10 support, and Solr image tags must start with the Solr version*
++
+The Solr Operator now supports Solr 10.
+Solr 10 needs a different `solr.xml`, different env vars and different `bin/solr` commands than Solr 9, so the operator reads the Solr version from `spec.solrImage.tag`.
+The tag must therefore start with the Solr version, e.g. `9.10.0`, `10.0.0`, `9.10`, `8.11`, `10`, `9.10.0-slim`, `10.0.0-my-custom-build` or `10.0.0@sha256:<digest>`.
+Tags without a version, such as `latest` or `slim`, and custom tags that don't start with the Solr version, are not accepted.
+The operator does not reconcile a SolrCloud with such a tag, or with an unsupported Solr major version; it emits an `UnsupportedSolrVersion` Warning event instead.
+*Before upgrading the operator*, check the image tags of your SolrClouds (including the `image.tag` value of the `solr` Helm chart) and change them where needed.
+SolrClouds that never set a tag got the operator's default tag at the time they were created (e.g. `8.11`), which is accepted.
+SolrClouds running Solr 8.11 or 9.x with an accepted tag are not changed by this upgrade, so their pods are not restarted.
+Changing a tag, e.g. from `latest` to `9.10.0`, changes the pod template and therefore restarts all Solr pods, even if the new tag points to the same image.
+If you pass `-Dsolr.allowPaths=...` via `solrOpts`, use `-Dsolr.security.allow.paths=...` when moving to Solr 10, which doesn't read the old camelCase name anymore.
+The Solr 10 `solr.xml` generated by the operator matches Solr 10's stock `solr.xml` and no longer contains the `metrics` element, so `-DmetricsEnabled=false` has no effect on Solr 10.
Review Comment:
This is not entirely correct - Solr 10 still supports this element, it has just been removed from the sample `solr.xml` shipped with Solr, since this is mainly used in tests.
Since this entire switch is a corner case, quite useless and perhaps not even documented (?) I propose that we skip the entire bullet.
```suggestion
```
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4371387919
##########
docs/modules/upgrade-notes/pages/upgrade-notes.adoc:
##########
@@ -136,6 +137,35 @@ _Note that the Helm chart version does not contain a `v` prefix, which the downl
=== v0.10.0
+* *Solr 10 support, and Solr image tags must start with the Solr version*
Review Comment:
Should we use some `====` subheaders in here, for better structure. Also, perhaps some bullets can merge into one?
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "danielmeint (via GitHub)" <gi...@apache.org>.
danielmeint commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4414485721
##########
helm/solr-operator/Chart.yaml:
##########
@@ -138,6 +138,18 @@ annotations:
url: https://github.com/apache/solr-operator/issues/535
- name: GitHub PR
url: https://github.com/apache/solr-operator/pull/571
+ - kind: added
+ description: Support for Solr 10. See the upgrade notes before upgrading a SolrCloud to Solr 10.
+ links:
+ - name: Github Issue
+ url: https://github.com/apache/solr-operator/issues/821
+ - name: Github PR
+ url: https://github.com/apache/solr-operator/pull/827
+ - kind: changed
+ description: The SolrCloud image tag must start with the Solr version (e.g. `10.0.0`, `9.10` or `8.11`). SolrClouds with other tags, such as `latest`, are no longer reconciled; see the upgrade notes before upgrading the operator.
Review Comment:
I added it to the `solr` chart as well; kept it here also, since the operator enforces it
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub) via issues" <is...@solr.apache.org>.
janhoy commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6605622252
> Now that Apache Solr 10.1 has officially been published, does the team have an updated estimated time of arrival (ETA) for the next Solr Operator release?
@aymen-guellala No release date is set. You should follow this repo and the solr dev@ mailing list for more information. And you can help accelerate the process by contributing PRs, reviews, testing prerelease versions etc.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "danielmeint (via GitHub)" <gi...@apache.org>.
danielmeint commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-4452228153
Awesome, thanks a lot for the thorough report, I really appreciate it.
Fair point on the discrepancy regarding the `solrMajorVersion` param. To clarify, the _CRD field_ is currently required, but the _helm chart_ defaults to 9. I don't have a strong intuition on whether that's the best way to handle it, to be honest. I'll at least update the PR description and upgrade notes to make this more explicit.
Same for disabling the prometheus exporter and the behavior change regarding `SOLR_MODULES`, I'll add more info to the upgrade notes to explain this better.
Again, thank you for taking the time 🙂
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "danielmeint (via GitHub)" <gi...@apache.org>.
danielmeint commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6374675273
Okay, would you definitely enforce strict `major.minor.patch`, though? The most recent operator release v0.9.1 defaults to `8.11 [here](https://github.com/apache/solr-operator/blob/v0.9.1/api/v1beta1/solrcloud_types.go#L40), for example, which gets written to the SolrCloud spec, so that would stop reconciling after an upgrade, right? 🤔
Would you be strongly opposed to allowing floating tags as well, as long as they start with a major (`8.11`, `9.10`, `10`)?
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6384766606
You are correct that we offer purposeful mutable tags now. While the internet is moving away from such practices and toward pinning, but that is mainly a deployment time choice by users, we can still offer those tags. Users tagging with sha `solr:10.1.0@sha256:9b7d...41c0` will likely use the full version.
I agree that we'd likely need to support `solr:9.11`, `solr:10-with-patches` and the like as well, which means we only need to look for the very first numeric part of the tag.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4389749115
##########
api/v1beta1/solrcloud_types.go:
##########
@@ -1327,6 +1328,49 @@ func (zkInfo ZookeeperConnectionInfo) ZkConnectionString() string {
return zkInfo.InternalConnectionString + zkInfo.ChRoot
}
+// solrImageTagVersionRegex matches Solr image tags, which must start with the Solr version, "<major>[.<minor>[.<patch>...]]".
+// Anything after the version must start with neither a digit nor a dot,
+// e.g. "10.0.0", "10.1.0-SNAPSHOT", "10.0.0.1", "10.0.0@sha256:...", "9.10-slim" or "8.11".
+// Short versions are accepted because released Solr Operator versions defaulted to tags such as "8.11",
+// and they cannot change their major version.
+var solrImageTagVersionRegex = regexp.MustCompile(`^(?P<major>\d+)(?:\.\d+)*(?:[^\d.].*)?$`)
+
+const (
+ // The range of Solr major versions that the Solr Operator supports.
+ MinSupportedSolrMajorVersion = 8
Review Comment:
Such changes should ideally only be made in major version, i.e. v1.0.0.
I was hoping to be able to release a last v0.x release with solr 10 support, but I'm also open to just jump straight to v1.0.0 and lift the floor to 9.0.0 if that makes us drop lots of baggage and simplify things. We can also discuss this in the dev@ thread about release.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "danielmeint (via GitHub)" <gi...@apache.org>.
danielmeint commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4414905917
##########
docs/modules/upgrade-notes/pages/upgrade-notes.adoc:
##########
@@ -136,6 +137,35 @@ _Note that the Helm chart version does not contain a `v` prefix, which the downl
=== v0.10.0
+* *Solr 10 support, and Solr image tags must start with the Solr version*
++
+The Solr Operator now supports Solr 10.
+Solr 10 needs a different `solr.xml`, different env vars and different `bin/solr` commands than Solr 9, so the operator reads the Solr version from `spec.solrImage.tag`.
+The tag must therefore start with the Solr version, e.g. `9.10.0`, `10.0.0`, `9.10`, `8.11`, `10`, `9.10.0-slim`, `10.0.0-my-custom-build` or `10.0.0@sha256:<digest>`.
+Tags without a version, such as `latest` or `slim`, and custom tags that don't start with the Solr version, are not accepted.
+The operator does not reconcile a SolrCloud with such a tag, or with an unsupported Solr major version; it emits an `UnsupportedSolrVersion` Warning event instead.
+*Before upgrading the operator*, check the image tags of your SolrClouds (including the `image.tag` value of the `solr` Helm chart) and change them where needed.
+SolrClouds that never set a tag got the operator's default tag at the time they were created (e.g. `8.11`), which is accepted.
+SolrClouds running Solr 8.11 or 9.x with an accepted tag are not changed by this upgrade, so their pods are not restarted.
+Changing a tag, e.g. from `latest` to `9.10.0`, changes the pod template and therefore restarts all Solr pods, even if the new tag points to the same image.
+If you pass `-Dsolr.allowPaths=...` via `solrOpts`, use `-Dsolr.security.allow.paths=...` when moving to Solr 10, which doesn't read the old camelCase name anymore.
Review Comment:
added a comment below; SOLR_ALLOW_PATHS is only read in v 9.6+ I found
##########
docs/modules/upgrade-notes/pages/upgrade-notes.adoc:
##########
@@ -136,6 +137,35 @@ _Note that the Helm chart version does not contain a `v` prefix, which the downl
=== v0.10.0
+* *Solr 10 support, and Solr image tags must start with the Solr version*
++
+The Solr Operator now supports Solr 10.
+Solr 10 needs a different `solr.xml`, different env vars and different `bin/solr` commands than Solr 9, so the operator reads the Solr version from `spec.solrImage.tag`.
+The tag must therefore start with the Solr version, e.g. `9.10.0`, `10.0.0`, `9.10`, `8.11`, `10`, `9.10.0-slim`, `10.0.0-my-custom-build` or `10.0.0@sha256:<digest>`.
+Tags without a version, such as `latest` or `slim`, and custom tags that don't start with the Solr version, are not accepted.
+The operator does not reconcile a SolrCloud with such a tag, or with an unsupported Solr major version; it emits an `UnsupportedSolrVersion` Warning event instead.
+*Before upgrading the operator*, check the image tags of your SolrClouds (including the `image.tag` value of the `solr` Helm chart) and change them where needed.
+SolrClouds that never set a tag got the operator's default tag at the time they were created (e.g. `8.11`), which is accepted.
+SolrClouds running Solr 8.11 or 9.x with an accepted tag are not changed by this upgrade, so their pods are not restarted.
+Changing a tag, e.g. from `latest` to `9.10.0`, changes the pod template and therefore restarts all Solr pods, even if the new tag points to the same image.
+If you pass `-Dsolr.allowPaths=...` via `solrOpts`, use `-Dsolr.security.allow.paths=...` when moving to Solr 10, which doesn't read the old camelCase name anymore.
Review Comment:
added a comment below; `SOLR_ALLOW_PATHS` is only read in v 9.6+ I found
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "HoustonPutman (via GitHub)" <gi...@apache.org>.
HoustonPutman commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6482541056
Yeah I'm quite unhappy with the long list of breaking changes, but I guess we just deal with it now.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6419348408
We discussed having a `solrMajorVersion` value as an **optional** override if you MUST use non-compliant tags. I'm not opposed to that, as it would be opt-in for the few. But Houston stated quite clearly above:
> But I actually want to stay away from solrMajorVersion entirely, I really really really hate that we would need that ever. For these bad edge cases, I can accept parsing tags. But that will go away soon, and will happen very rarely hopefully.
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "danielmeint (via GitHub)" <gi...@apache.org>.
danielmeint commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6325089819
> But I actually want to stay away from solrMajorVersion entirely [...] I can accept parsing tags.
Okay, I hear ya :) So you'd enforce tags leading with the major version; and if it's unparseable (for whatever reason), fail loudly? What about `latest` as a "special case"?
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "HoustonPutman (via GitHub)" <gi...@apache.org>.
HoustonPutman commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6474610877
> Solr 10 renamed the solr.log.dir sysprop to solr.logs.dir
😭
> 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.
So we just need to document 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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "danielmeint (via GitHub)" <gi...@apache.org>.
danielmeint commented on code in PR #827:
URL: https://github.com/apache/solr-operator/pull/827#discussion_r4414463334
##########
docs/modules/upgrade-notes/pages/upgrade-notes.adoc:
##########
@@ -136,6 +137,35 @@ _Note that the Helm chart version does not contain a `v` prefix, which the downl
=== v0.10.0
+* *Solr 10 support, and Solr image tags must start with the Solr version*
++
+The Solr Operator now supports Solr 10.
+Solr 10 needs a different `solr.xml`, different env vars and different `bin/solr` commands than Solr 9, so the operator reads the Solr version from `spec.solrImage.tag`.
+The tag must therefore start with the Solr version, e.g. `9.10.0`, `10.0.0`, `9.10`, `8.11`, `10`, `9.10.0-slim`, `10.0.0-my-custom-build` or `10.0.0@sha256:<digest>`.
+Tags without a version, such as `latest` or `slim`, and custom tags that don't start with the Solr version, are not accepted.
+The operator does not reconcile a SolrCloud with such a tag, or with an unsupported Solr major version; it emits an `UnsupportedSolrVersion` Warning event instead.
+*Before upgrading the operator*, check the image tags of your SolrClouds (including the `image.tag` value of the `solr` Helm chart) and change them where needed.
+SolrClouds that never set a tag got the operator's default tag at the time they were created (e.g. `8.11`), which is accepted.
+SolrClouds running Solr 8.11 or 9.x with an accepted tag are not changed by this upgrade, so their pods are not restarted.
+Changing a tag, e.g. from `latest` to `9.10.0`, changes the pod template and therefore restarts all Solr pods, even if the new tag points to the same image.
+If you pass `-Dsolr.allowPaths=...` via `solrOpts`, use `-Dsolr.security.allow.paths=...` when moving to Solr 10, which doesn't read the old camelCase name anymore.
Review Comment:
👍 Added a sentence below, seems to only be mapped from 9.6 onward afaics
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
Re: [PR] Add Solr 10 compatibility support [solr-operator]
Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #827:
URL: https://github.com/apache/solr-operator/pull/827#issuecomment-6454182175
> As is noted in the issue, the prometheusExporter is gone from Solr 10 and upgrading with it will not work, it has to be disabled first. Failing to remove it caused the upgrade process to stall, requiring a rollback.
It would be beneficial if the Operator could log a fat ERROR if attempting to start a `SolrPrometheusExporter` based on a Solr10.x image. Log and abort, instead of failing with some command not found error msg (or whatever it does now?)
--
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: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org