I think I'm going to cut the v0.4.0 release branch later this week. There are 3 PRs remaining for this release which should be merged by Wednesday or Thursday:
- Configuration options to support an additional client TLS cert in addition to the server certificate <https://github.com/apache/solr-operator/pull/312> - Change information in release wizard <https://github.com/apache/solr-operator/pull/315> - Option to watch for updates to the mTLS cert used by the operator to call Solr pods <https://github.com/apache/solr-operator/pull/318> The v0.5.0 release shouldn't be too far after v0.4.0, and we can focus on the backup stuff and Kubernetes v1.22 support then. - Houston On Mon, Aug 2, 2021 at 5:14 PM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > Thanks and done (see "Solr Version Expectations for Operator")! > > On Mon, Aug 2, 2021 at 12:03 PM Houston Putman <houstonput...@gmail.com> > wrote: > >> > >> I'm starting to work through a few potential > >> improvements, specifically involving the operator's backup support > > > > > > Sounds good. Tim and I are taking some time with this more advanced TLS > support for Solr Clouds, so these may be able to land in v0.4.0. > > But if they end up in v0.5.0, it's not the end of the world. That will > have to be released sometime soon anyway, to add support for Kubernetes > v1.22 clusters. > > > >> One question this raises in my mind though: are we targeting > >> particular Solr operator releases at particular Solr versions (or > >> ranges of Solr versions)? > > > > > > Mind asking this on another thread? I have a response ready, but would > love to have that discussion be separate from the v0.4.0 release. > > > > - Houston > > > > On Fri, Jul 30, 2021 at 3:29 PM Jason Gerlowski <gerlowsk...@gmail.com> > wrote: > >> > >> > I suggest that we have start a feature freeze in two weeks, on August > 4 > >> > >> Sounds good to me. I'm starting to work through a few potential > >> improvements, specifically involving the operator's backup support, > >> but don't need to target any particular version afaik, as long as > >> there's no blocker or restriction on doing other releases down the > >> road. > >> > >> One question this raises in my mind though: are we targeting > >> particular Solr operator releases at particular Solr versions (or > >> ranges of Solr versions)? The repo README calls out Kubernetes > >> version compatibility but doesn't speak to Solr compatibility that I > >> saw. I imagine this isn't a huge issue generally assuming Solr's > >> docker image structure stays relatively unchanged, but it does matter > >> in some situations: e.g. if the operator wanted to add a feature > >> taking advantage of a Solr feature only introduced in, say, 8.8. > >> Maybe this is its own thread though... > >> > >> Best, > >> > >> Jason > >> > >> On Tue, Jul 27, 2021 at 10:37 AM Houston Putman < > houstonput...@gmail.com> wrote: > >> > > >> > The Solr helm chart is mainly merely templating the SolrCloud CRD. > There are a few other things it does, such as create a ServiceAccount if > one is requested, but it does not do anything with regard to collections. > You likely won't see anything regarding collection management for a long > time (if at all) in the Solr Operator. > >> > > >> > Though collection management and replica placement are something > everyone deals with, so I'm sure people would be interested if you wanted > to share. (Probably in a separate thread though) > >> > > >> > - Houston > >> > > >> > On Fri, Jul 23, 2021 at 2:14 PM Joel Bernstein <joels...@gmail.com> > wrote: > >> >> > >> >> I was curious about the "Solr helm chart" that Houston mentioned? I > ask because I'm knee deep in a set of python scripts that create Solr > Collections using the Solr operator. I just wanted make sure I'm not > missing some Solr collection level support coming out. > >> >> > >> >> Also if anyone is interested I can share the python scripts I'm > working on when they are ready next week. The scripts handle replica > placement directly rather than relying on Solr for placement. > >> >> > >> >> Joel Bernstein > >> >> http://joelsolr.blogspot.com/ > >> >> > >> >> > >> >> On Wed, Jul 21, 2021 at 11:18 AM Timothy Potter < > thelabd...@gmail.com> wrote: > >> >>> > >> >>> Sounds good Houston! Thanks for initiating this process ;-) On my > >> >>> side, I'd like to get fixes in for: > >> >>> > >> >>> https://github.com/apache/solr-operator/issues/291 > >> >>> https://github.com/apache/solr-operator/issues/289 > >> >>> https://github.com/apache/solr-operator/issues/274 > >> >>> > >> >>> Should have PR's ready for review for these by the end of this week. > >> >>> > >> >>> Cheers, > >> >>> Tim > >> >>> > >> >>> On Wed, Jul 21, 2021 at 9:14 AM Houston Putman <hous...@apache.org> > wrote: > >> >>> > > >> >>> > Hello everyone, > >> >>> > > >> >>> > As you might have seen on various lists, there is has been a lot > of good stuff going into the Solr Operator recently. This includes: > >> >>> > > >> >>> > A Solr helm chart! > >> >>> > Scheduled restarts > >> >>> > More Provided Zookeeper options > >> >>> > Customization of Service Account (Allows for running on OKD) > >> >>> > More TLS options, such as common-endpoint ingress termination and > mounted cert options > >> >>> > A Solr Operator base image with no CVEs > >> >>> > > >> >>> > > >> >>> > There are still some features that folks are trying to get in, so > I suggest that we have start a feature freeze in two weeks, on August 4. > Then we can start the v0.4.0 release process, which should hopefully go > very smoothly given the automation around it! > >> >>> > > >> >>> > Let me know if anyone has larger features that will require more > time to get in. > >> >>> > > >> >>> > Note: we will likely not be changing the supported Kubernetes > version in this release. We may need another v0.5.0 release, not-so-long > after v0.4.0, that supports Kubernetes v1.22, but we can cross that bridge > when we get to it. > >> >>> > > >> >>> > - Houston > >> >>> > >> >>> > --------------------------------------------------------------------- > >> >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >> >>> For additional commands, e-mail: dev-h...@solr.apache.org > >> >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >> For additional commands, e-mail: dev-h...@solr.apache.org > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
