> I'm a big fan of the second approach ... I think it's fine to make those
> assumptions.
I was leaning towards approach (2) as well, so that all sounds good to me.
I'd have to think a little more about what defaults make most sense
for the non-incremental use case before I could weigh in intell
Very good question.
Currently we "support" all recent versions of Solr, meaning 7 & 8.
This doesn't mean that Solr 6 won't work, it just hasn't been
thoroughly tested.
We do eventually plan on limiting support to a range of Solr versions.
I imagine that once Solr 9 is released, we will begin s
Thanks and done (see "Solr Version Expectations for Operator")!
On Mon, Aug 2, 2021 at 12:03 PM Houston Putman 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 thi
Hey all,
Breaking out this thread from a side-comment on "Proposal to cut the
v0.4.0 release soon".
Are we targeting particular Solr operator releases at particular Solr
versions (or ranges of Solr versions)? (If not, should we be?)
The repo README calls out Kubernetes version compatibility but
Hey Jason, thanks for the thorough investigation here.
I'm a big fan of the second approach, but in this case I think we'd really
only need 1 option: *incremental: true/false*
If the user specifies an incremental backup, we know that:
- They do not want a unique name
- The data already the
>
> 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 th
