Hi and thank you for the suggestion.

We did briefly look at it, but were not intending to do it *yet*. We might
now if this becomes the most straightforward way to do it.


On Thu, Dec 23, 2021 at 2:37 AM Timothy Potter <[email protected]> wrote:

> I think it would be great if you could switch to using the Solr
> operator. It supports loading a custom solr.xml from a ConfigMap (and
> restarting Solr pods if the ConfigMap changes). The operator provides
> a common approach for running Solr on Kubernetes and is maintained by
> Solr committers. If you can't migrate, then I'd use an initContainer
> to prep the custom solr.xml for the main container.
>
> Cheers,
> Tim
>
> On Wed, Dec 22, 2021 at 7:37 AM Jonathan Tan <[email protected]> wrote:
> >
> > Hi!
> >
> > I'm using the bitnami SOLR helm chart (
> > https://github.com/bitnami/bitnami-docker-solr), and using it to deploy
> a
> > Solr Cloud cluster.
> >
> > I'm trying to figure out how to update the solr.xml file.
> > I'm aware of the `bin/solr` utility that can be used to update the file,
> > but I'm not sure if that's a particularly "container"/IaC approach, as
> now
> > I'm manually modifying the state of the cluster, rather than let it be an
> > automated/pre-canned process.
> >
> > The main thing that's come to mind is:
> > - have an initContainer with a custom script, and a solr image that has
> the
> > modified solr.xml file baked into it
> > - the custom script checks SOLR for when the existing solr.xml file was
> > last modified (I've got no idea how to do this)
> > - if the last modified of the solr.xml file in ZK is older than the one
> in
> > the initContainer's custom script, then run the `bin/solr zk cp`
> function,
> > otherwise, just proceed.
> >
> > *however*
> > I'm wondering if there are other approaches, and was hoping for some
> > voices-of-experience.
> >
> > Thank you!
> > Jonathan
>

Reply via email to