Do not override solr-update-core-and-start in the compose and stack files - #471
Do not override solr-update-core-and-start in the compose and stack files#471reekitconcept wants to merge 1 commit into
Conversation
6177862 to
2fd35e3
Compare
2fd35e3 to
15abcd7
Compare
|
Deployment note: this needs a Solr reindex after deploying. The solr service spec changes (command + image tag), so Swarm recreates the solr container — and since the service has no volume, the container comes up with an empty core. Run the usual This is not specific to this PR — today any deploy that recreates the solr container costs a full reindex. Proposal to remove that coupling by persisting Silver lining: the sha pin in this PR makes future reindexes more predictable — with the old floating |
…iles The ghcr.io/kitconcept/solr image sets CMD ["solr-update-core-and-start"], which refreshes the config of an already existing core before calling solr-precreate. All three places that start Solr then set a command: of their own with plain solr-precreate, which replaces the CMD and disables the refresh, so a core that already exists on a volume keeps its old config. Call the script explicitly instead of relying on the CMD, so adding a command: back later cannot silently switch it off again.
15abcd7 to
c1c8eef
Compare
reekitconcept
changed the title
1 participant
Companion of kitconcept.solr#108 (merged): the compose and stack files overrode the image's
CMDwithsolr-precreate, which silently disabled thesolr-update-core-and-startscript baked into the image — so core config changes shipped with a new image never reached an existing core. The script is now called explicitly incommand:, so adding acommand:back later cannot silently switch it off again.Scope note: this PR now contains only the command fix. The by-revision pinning of the kitconcept.solr artifacts (backend, frontend, solr image) that used to be the second commit here has moved to #474, which pins to a newer revision that also carries the Plate RAG chunking fix (kitconcept.solr#112). Keeping the pinning in both PRs would only create conflicts between them.
Deployment note (unchanged, see comment below): deploying this recreates the solr container, and since the solr service has no volume the core comes up empty — a reindex is needed after the deploy. Proposal to decouple that: #578.