You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Jason Gerlowski <ge...@gmail.com> on 2021/08/02 21:13:04 UTC
Solr Version Expectations for Operator
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 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.
Best,
Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Solr Version Expectations for Operator
Posted by Houston Putman <ho...@gmail.com>.
Made a PR that better outlines the Solr Operator compatibility with
different Kubernetes and Solr versions.
https://github.com/apache/solr-operator/pull/319
On Wed, Aug 4, 2021 at 8:47 AM Jason Gerlowski <ge...@gmail.com>
wrote:
> That all seems sane to me. I'll create a Github ticket around adding
> a note to the README about Solr versions.
>
> Jason
>
> On Mon, Aug 2, 2021 at 5:24 PM Houston Putman <ho...@gmail.com>
> wrote:
> >
> > 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 supporting 8+ on
> the next Solr Operator release.
> >
> > But we could explicitly call out support for 7.7.2+ starting with
> v0.4.0, if we so desire.
> >
> >
> > We have been adding a few things to Solr, so that in the future the
> operator code can be less complex.
> >
> > We should compile a list so that when we are upgrading the minimum Solr
> version, we have an easy way to see the Solr Operator changes that should
> be made in response.
> >
> >
> > I would say that you can add support for a feature that requires a newer
> version of Solr, it just has to be optional and turned off by default.
> >
> > The documentation in the CRD as well as the Solr Operator docs should
> plainly state the minimum Solr version needed for that feature.
> >
> > But that's my opinion, I would love to hear from others.
> >
> >
> > - Houston
> >
> >
> > On Mon, Aug 2, 2021 at 5:13 PM Jason Gerlowski <ge...@gmail.com>
> wrote:
> >>
> >> 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 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.
> >>
> >> Best,
> >>
> >> Jason
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> For additional commands, e-mail: dev-help@solr.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Solr Version Expectations for Operator
Posted by Jason Gerlowski <ge...@gmail.com>.
That all seems sane to me. I'll create a Github ticket around adding
a note to the README about Solr versions.
Jason
On Mon, Aug 2, 2021 at 5:24 PM Houston Putman <ho...@gmail.com> wrote:
>
> 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 supporting 8+ on the next Solr Operator release.
>
> But we could explicitly call out support for 7.7.2+ starting with v0.4.0, if we so desire.
>
>
> We have been adding a few things to Solr, so that in the future the operator code can be less complex.
>
> We should compile a list so that when we are upgrading the minimum Solr version, we have an easy way to see the Solr Operator changes that should be made in response.
>
>
> I would say that you can add support for a feature that requires a newer version of Solr, it just has to be optional and turned off by default.
>
> The documentation in the CRD as well as the Solr Operator docs should plainly state the minimum Solr version needed for that feature.
>
> But that's my opinion, I would love to hear from others.
>
>
> - Houston
>
>
> On Mon, Aug 2, 2021 at 5:13 PM Jason Gerlowski <ge...@gmail.com> wrote:
>>
>> 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 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.
>>
>> Best,
>>
>> Jason
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Solr Version Expectations for Operator
Posted by Houston Putman <ho...@gmail.com>.
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 supporting 8+ on the
next Solr Operator release.
But we could explicitly call out support for 7.7.2+ starting with v0.4.0,
if we so desire.
We have been adding a few things to Solr, so that in the future the
operator code can be less complex.
We should compile a list so that when we are upgrading the minimum Solr
version, we have an easy way to see the Solr Operator changes that should
be made in response.
I would say that you can add support for a feature that requires a newer
version of Solr, it just has to be optional and turned off by default.
The documentation in the CRD as well as the Solr Operator docs should
plainly state the minimum Solr version needed for that feature.
But that's my opinion, I would love to hear from others.
- Houston
On Mon, Aug 2, 2021 at 5:13 PM Jason Gerlowski <ge...@gmail.com>
wrote:
> 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 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.
>
> Best,
>
> Jason
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>