janhoy opened a new issue, #878:
URL: https://github.com/apache/solr-operator/issues/878
Operator >= v0.8 has a minimum supported Solr version 8.11. From operator
v1.0.0 let's lift the this floor to 9.0.0.
Changes this will allow (LLM 🤖 generated list):
## Version gating
- `MinSupportedSolrMajorVersion` goes from `8` to `9` in
`api/v1beta1/solrcloud_types.go`. One constant, but it collapses the "pre-10
means 8 *or* 9" reasoning throughout the codebase into "pre-10 means 9", which
is what makes every bullet below possible.
- The major-only check in `SolrMajorVersionFromTag` becomes correct by
construction, so no minor-version validation ever has to be added: today tags
`8.0`–`8.5` pass validation and are then handed a generated `solr.xml` that
Solr refuses to load, because `allowPaths` only arrived in Solr 8.6.
- Any future `SolrVersionAtLeast(9)` call becomes dead weight rather than a
needed branch, so the version-gating helper only ever has to express one real
boundary (10) instead of two.
## solr.xml and classpath
- `<str name="modules">${solr.modules:}</str>` and the `SOLR_MODULES` env
var exist from **Solr 9.0** (`ModuleUtils` reads
`System.getenv("SOLR_MODULES")`) and are absent in 8.11, so the pre-10 path can
use `modules` exactly like the Solr 10 path.
- That deletes the `isSolr10` branch in `GenerateAdditionalLibXMLPart`
(`controllers/util/solr_util.go`) — modules become one code path instead of two.
- `DistLibs = "/opt/solr/dist"` can be deleted outright: Solr 9's
`packaging/build.gradle` has no `dist` directory at all, so the operator is
already injecting a nonexistent `sharedLib` path into every Solr 9 cloud that
sets `solrModules`.
- `ContribLibs = "/opt/solr/contrib/%s/lib"` can be deleted too: on Solr 9
it only resolves because the Solr Dockerfile keeps a back-compat symlink (`ln
-s /opt/solr/modules /opt/solr/contrib`). `ModuleLibs` becomes the only form.
- `DefaultSolrXML` and `DefaultSolrXMLForSolr10` converge: both get
`modules`, `allowUrls` and `${solr.port.advertise:0}`. The remaining real diff
shrinks to `hostContext`, `genericCoreNodeNames` and `<metrics>`, which may
make a single parameterized template viable instead of two literal templates.
## Prometheus exporter
- `unsupportedExporterSolrVersion` already refuses any exporter on Solr 10
or later, so with a 9.0 floor the exporter can only ever run against **9.x** —
a single Solr line, with no version branching left to reason about.
- `prometheus_exporter_util.go` carries a TODO keyed to exactly this floor —
*"When 9.0 is the minimum supported version, this can be `/-/healthy`"* —
replacing the `/metrics?name[]=` probe hack.
- `DefaultPrometheusExporterEntrypoint`, the `CONFIG_FILE` default and the
TLS wrapper script in `solr_tls_util.go` can all move off
`/opt/solr/contrib/prometheus-exporter/...` to the real
`/opt/solr/prometheus-exporter/...`, dropping the dependency on the Solr 8-era
compat symlink.
## API compat shims
- `IsNotSupportedApiError` in `controllers/util/solr_api/v2.go` can drop the
`"no core retrieved for null"` match, which is 8.11's v2 unknown-path wording;
Solr 9.x says `"Cannot find API for the path"`.
## Tests and CI
- `tests/e2e/solrcloud_scaling_test.go`: the Scale Down Abandon test's
`Skip` for Solr 8 goes away, along with its brittle
`strings.Contains(solrImage, ":8") || strings.Contains(solrImage, "8.")`
image-string sniffing.
- `tests/e2e/test_utils_test.go`: the `Or(...)` assertion carrying an
8.11-only NPE-versus-proxy-error branch reduces to a single expected string.
- `.github/workflows/e2e-tests.yaml`: the commented-out `'8.11'` entry can
be dropped rather than remaining a perpetually untested support claim.
- `controllers/util/solr_util_test.go`: in `TestSolrMajorVersion`, the
`8.11.4`, `8.11` and `8.9` cases flip from "parses to 8" to "rejected".
> [!NOTE]
> This list assumes #827 is already merged — it is written against that
branch's version-detection code (`SolrMajorVersion`, `ParseSolrMajorVersion`,
`SolrVersionAtLeast`, `MinSupportedSolrMajorVersion`) and its Solr 10 handling,
none of which is on `main` yet.
--
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]
