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 2022/10/31 20:23:47 UTC
[DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Hey all,
This morning I published SIP-16, which proposes the changes necessary
to "finish" (i.e. plug coverage gaps and polish) Solr's v2 APIs and a
path to deprecating Solr's v1 APIs.
The SIP can be found here:
https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation
Please read the SIP description and come back here for discussion. As
the discussion progresses we will update the SIP page with any
outcomes and eventually move things to a VOTE (or lazy consensus).
Looking forward to hearing your feedback!
Best,
Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by David Smiley <ds...@apache.org>.
Yeah I agree; no need to make a prediction on timing/versions at this point.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Nov 8, 2022 at 10:32 AM Jason Gerlowski <ge...@gmail.com>
wrote:
> > removing v1 completely on 10.0 should depend on how soon 10.0 is
> happening
>
> I agree on both points: we need to give adequate time for the
> ecosystem and users to upgrade, and the major-release cadence will
> play a big role there.
>
> In general I think the "when should we remove v1" question is going to
> be really hard to answer this far out. We can try to forecast that
> here, but it almost seems futile. That's the main reason that the SIP
> is structured around getting to deprecation and **not** around removal
> itself. Deprecation is mostly "just" a matter of getting the pre-reqs
> done. Removal involves other factors that I don't think we can
> predict at this point.
>
> Best,
>
> Jason
>
> On Mon, Nov 7, 2022 at 10:10 PM Noble Paul <no...@gmail.com> wrote:
> >
> > removing v1 completely on 10.0 should depend on how soon 10.0 is
> happening.
> > are we prepared to do it within a year?
> >
> > On Tue, Nov 8, 2022 at 9:47 AM Jan Høydahl <ja...@cominvent.com>
> wrote:
> >
> > > I'm not against a more aggressive plan, i.e. remove v1 in 10.0 - users
> > > will just have to stay longer on 9.x if they don't want to change their
> > > apps.
> > > My only worry there is that the Solr 10.0 release MAY happen already in
> > > Q2/Q3 2023, and that leaves just a few months preparation time for the
> > > entire ecosystem to change (other language clients, crawlers,
> Blacklight
> > > etc).
> > >
> > > Let's hear other voices on this too.
> > >
> > > Jan
> > >
> > > > 7. nov. 2022 kl. 13:41 skrev Jason Gerlowski <gerlowskija@gmail.com
> >:
> > > >
> > > > Hi Jan,
> > > >
> > > > I guess I'd be a bit uncomfortable with deprecating v1 until v2 has
> > > > had some decent dog-fooding. That's probably why the SIP suggests
> > > > that deprecation coincide with "v2-used-internally": because the
> > > > earlier "v2-complete" doesn't mean that anything even uses the v2 API
> > > > yet. But that's just my two cents: if there's consensus that we have
> > > > enough confidence in v2, or that it'd be valuable to get the
> > > > deprecation warning out there earlier, then I can live with that.
> > > >
> > > > On your second point, I'm a little leery of tying "v2-complete",
> > > > "v2-used-internally", and "eventual removal" to any particular
> > > > releases - mostly because the timing around our releases has been
> > > > somewhat unpredictable. I certainly agree that v1 removal has to
> > > > happen on a major-version boundary, and if 10.0 comes around quickly,
> > > > then the timeline you suggest seems pretty plausible. But 10.0 might
> > > > take much longer (9.0 took 3 years after all), in which case it seems
> > > > reasonable to me that v1 could be removed for 10.0 if all the
> > > > prerequisites happen early enough in the 9.x line. I guess I'm
> > > > worried about a scenario where both 10.x and 11.x are long release
> > > > lines, and we end up supporting v1 forever. Any thoughts on that?
> > > >
> > > > Best,
> > > >
> > > > Jason
> > > >
> > > > On Sun, Nov 6, 2022 at 3:04 PM Jan Høydahl <ja...@cominvent.com>
> > > wrote:
> > > >>
> > > >> Both.
> > > >>
> > > >> 9x: v2 complete, deprecate v1 (and adding some deprecation noise to
> > > logs)
> > > >> 10.0 Switch to using v2 internally
> > > >> 11.0 Remove v1
> > > >>
> > > >> Jan
> > > >>
> > > >>> 4. nov. 2022 kl. 16:25 skrev Jason Gerlowski <
> gerlowskija@gmail.com>:
> > > >>>
> > > >>> Hi Jan,
> > > >>>
> > > >>> Just trying to make sure I understand your suggestion. Are you
> > > suggesting:
> > > >>>
> > > >>> (1) that we announce v1 as deprecated at "V2-API-Complete"
> (instead of
> > > >>> the later "v2-API-used-internally")? Or...
> > > >>> (2) that we plan "v2-API-used-internally" to coincide with 10.0?
> > > >>> (3) Or both?
> > > >>>
> > > >>> Best,
> > > >>>
> > > >>> Jason
> > > >>>
> > > >>> On Mon, Oct 31, 2022 at 5:04 PM Jan Høydahl <jan.asf@cominvent.com
> >
> > > wrote:
> > > >>>>
> > > >>>> Thanks for a thorough SIP.
> > > >>>>
> > > >>>> Wrt deprecation plan, could we not have "v2-API-Complete" in e.g.
> 9.5
> > > (and deprecate v1). Then we wait until 10.0 with
> "v2-API-used-internally",
> > > and 11.0 for removing v1. Say we release 10.0 in March 2023, then the
> new
> > > main will be 11.0 and we can already remove v1 in main.
> > > >>>>
> > > >>>> Looking forward to code generating SolrJ classes. And perhaps
> > > community members actively using some other prog.language will be
> empowered
> > > to auto generate 90% of such clients.
> > > >>>>
> > > >>>> Jan
> > > >>>>
> > > >>>>> 31. okt. 2022 kl. 21:23 skrev Jason Gerlowski <
> gerlowskija@gmail.com
> > > >:
> > > >>>>>
> > > >>>>> Hey all,
> > > >>>>>
> > > >>>>> This morning I published SIP-16, which proposes the changes
> necessary
> > > >>>>> to "finish" (i.e. plug coverage gaps and polish) Solr's v2 APIs
> and a
> > > >>>>> path to deprecating Solr's v1 APIs.
> > > >>>>>
> > > >>>>> The SIP can be found here:
> > > >>>>>
> > >
> https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation
> > > >>>>>
> > > >>>>> Please read the SIP description and come back here for
> discussion.
> > > As
> > > >>>>> the discussion progresses we will update the SIP page with any
> > > >>>>> outcomes and eventually move things to a VOTE (or lazy
> consensus).
> > > >>>>>
> > > >>>>> Looking forward to hearing your feedback!
> > > >>>>>
> > > >>>>> 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
> > > >>>>
> > > >>>
> > > >>>
> ---------------------------------------------------------------------
> > > >>> 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
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> >
> > --
> > -----------------------------------------------------
> > Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by Jason Gerlowski <ge...@gmail.com>.
> removing v1 completely on 10.0 should depend on how soon 10.0 is happening
I agree on both points: we need to give adequate time for the
ecosystem and users to upgrade, and the major-release cadence will
play a big role there.
In general I think the "when should we remove v1" question is going to
be really hard to answer this far out. We can try to forecast that
here, but it almost seems futile. That's the main reason that the SIP
is structured around getting to deprecation and **not** around removal
itself. Deprecation is mostly "just" a matter of getting the pre-reqs
done. Removal involves other factors that I don't think we can
predict at this point.
Best,
Jason
On Mon, Nov 7, 2022 at 10:10 PM Noble Paul <no...@gmail.com> wrote:
>
> removing v1 completely on 10.0 should depend on how soon 10.0 is happening.
> are we prepared to do it within a year?
>
> On Tue, Nov 8, 2022 at 9:47 AM Jan Høydahl <ja...@cominvent.com> wrote:
>
> > I'm not against a more aggressive plan, i.e. remove v1 in 10.0 - users
> > will just have to stay longer on 9.x if they don't want to change their
> > apps.
> > My only worry there is that the Solr 10.0 release MAY happen already in
> > Q2/Q3 2023, and that leaves just a few months preparation time for the
> > entire ecosystem to change (other language clients, crawlers, Blacklight
> > etc).
> >
> > Let's hear other voices on this too.
> >
> > Jan
> >
> > > 7. nov. 2022 kl. 13:41 skrev Jason Gerlowski <ge...@gmail.com>:
> > >
> > > Hi Jan,
> > >
> > > I guess I'd be a bit uncomfortable with deprecating v1 until v2 has
> > > had some decent dog-fooding. That's probably why the SIP suggests
> > > that deprecation coincide with "v2-used-internally": because the
> > > earlier "v2-complete" doesn't mean that anything even uses the v2 API
> > > yet. But that's just my two cents: if there's consensus that we have
> > > enough confidence in v2, or that it'd be valuable to get the
> > > deprecation warning out there earlier, then I can live with that.
> > >
> > > On your second point, I'm a little leery of tying "v2-complete",
> > > "v2-used-internally", and "eventual removal" to any particular
> > > releases - mostly because the timing around our releases has been
> > > somewhat unpredictable. I certainly agree that v1 removal has to
> > > happen on a major-version boundary, and if 10.0 comes around quickly,
> > > then the timeline you suggest seems pretty plausible. But 10.0 might
> > > take much longer (9.0 took 3 years after all), in which case it seems
> > > reasonable to me that v1 could be removed for 10.0 if all the
> > > prerequisites happen early enough in the 9.x line. I guess I'm
> > > worried about a scenario where both 10.x and 11.x are long release
> > > lines, and we end up supporting v1 forever. Any thoughts on that?
> > >
> > > Best,
> > >
> > > Jason
> > >
> > > On Sun, Nov 6, 2022 at 3:04 PM Jan Høydahl <ja...@cominvent.com>
> > wrote:
> > >>
> > >> Both.
> > >>
> > >> 9x: v2 complete, deprecate v1 (and adding some deprecation noise to
> > logs)
> > >> 10.0 Switch to using v2 internally
> > >> 11.0 Remove v1
> > >>
> > >> Jan
> > >>
> > >>> 4. nov. 2022 kl. 16:25 skrev Jason Gerlowski <ge...@gmail.com>:
> > >>>
> > >>> Hi Jan,
> > >>>
> > >>> Just trying to make sure I understand your suggestion. Are you
> > suggesting:
> > >>>
> > >>> (1) that we announce v1 as deprecated at "V2-API-Complete" (instead of
> > >>> the later "v2-API-used-internally")? Or...
> > >>> (2) that we plan "v2-API-used-internally" to coincide with 10.0?
> > >>> (3) Or both?
> > >>>
> > >>> Best,
> > >>>
> > >>> Jason
> > >>>
> > >>> On Mon, Oct 31, 2022 at 5:04 PM Jan Høydahl <ja...@cominvent.com>
> > wrote:
> > >>>>
> > >>>> Thanks for a thorough SIP.
> > >>>>
> > >>>> Wrt deprecation plan, could we not have "v2-API-Complete" in e.g. 9.5
> > (and deprecate v1). Then we wait until 10.0 with "v2-API-used-internally",
> > and 11.0 for removing v1. Say we release 10.0 in March 2023, then the new
> > main will be 11.0 and we can already remove v1 in main.
> > >>>>
> > >>>> Looking forward to code generating SolrJ classes. And perhaps
> > community members actively using some other prog.language will be empowered
> > to auto generate 90% of such clients.
> > >>>>
> > >>>> Jan
> > >>>>
> > >>>>> 31. okt. 2022 kl. 21:23 skrev Jason Gerlowski <gerlowskija@gmail.com
> > >:
> > >>>>>
> > >>>>> Hey all,
> > >>>>>
> > >>>>> This morning I published SIP-16, which proposes the changes necessary
> > >>>>> to "finish" (i.e. plug coverage gaps and polish) Solr's v2 APIs and a
> > >>>>> path to deprecating Solr's v1 APIs.
> > >>>>>
> > >>>>> The SIP can be found here:
> > >>>>>
> > https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation
> > >>>>>
> > >>>>> Please read the SIP description and come back here for discussion.
> > As
> > >>>>> the discussion progresses we will update the SIP page with any
> > >>>>> outcomes and eventually move things to a VOTE (or lazy consensus).
> > >>>>>
> > >>>>> Looking forward to hearing your feedback!
> > >>>>>
> > >>>>> 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
> > >>>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> 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
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
> --
> -----------------------------------------------------
> Noble Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by Noble Paul <no...@gmail.com>.
removing v1 completely on 10.0 should depend on how soon 10.0 is happening.
are we prepared to do it within a year?
On Tue, Nov 8, 2022 at 9:47 AM Jan Høydahl <ja...@cominvent.com> wrote:
> I'm not against a more aggressive plan, i.e. remove v1 in 10.0 - users
> will just have to stay longer on 9.x if they don't want to change their
> apps.
> My only worry there is that the Solr 10.0 release MAY happen already in
> Q2/Q3 2023, and that leaves just a few months preparation time for the
> entire ecosystem to change (other language clients, crawlers, Blacklight
> etc).
>
> Let's hear other voices on this too.
>
> Jan
>
> > 7. nov. 2022 kl. 13:41 skrev Jason Gerlowski <ge...@gmail.com>:
> >
> > Hi Jan,
> >
> > I guess I'd be a bit uncomfortable with deprecating v1 until v2 has
> > had some decent dog-fooding. That's probably why the SIP suggests
> > that deprecation coincide with "v2-used-internally": because the
> > earlier "v2-complete" doesn't mean that anything even uses the v2 API
> > yet. But that's just my two cents: if there's consensus that we have
> > enough confidence in v2, or that it'd be valuable to get the
> > deprecation warning out there earlier, then I can live with that.
> >
> > On your second point, I'm a little leery of tying "v2-complete",
> > "v2-used-internally", and "eventual removal" to any particular
> > releases - mostly because the timing around our releases has been
> > somewhat unpredictable. I certainly agree that v1 removal has to
> > happen on a major-version boundary, and if 10.0 comes around quickly,
> > then the timeline you suggest seems pretty plausible. But 10.0 might
> > take much longer (9.0 took 3 years after all), in which case it seems
> > reasonable to me that v1 could be removed for 10.0 if all the
> > prerequisites happen early enough in the 9.x line. I guess I'm
> > worried about a scenario where both 10.x and 11.x are long release
> > lines, and we end up supporting v1 forever. Any thoughts on that?
> >
> > Best,
> >
> > Jason
> >
> > On Sun, Nov 6, 2022 at 3:04 PM Jan Høydahl <ja...@cominvent.com>
> wrote:
> >>
> >> Both.
> >>
> >> 9x: v2 complete, deprecate v1 (and adding some deprecation noise to
> logs)
> >> 10.0 Switch to using v2 internally
> >> 11.0 Remove v1
> >>
> >> Jan
> >>
> >>> 4. nov. 2022 kl. 16:25 skrev Jason Gerlowski <ge...@gmail.com>:
> >>>
> >>> Hi Jan,
> >>>
> >>> Just trying to make sure I understand your suggestion. Are you
> suggesting:
> >>>
> >>> (1) that we announce v1 as deprecated at "V2-API-Complete" (instead of
> >>> the later "v2-API-used-internally")? Or...
> >>> (2) that we plan "v2-API-used-internally" to coincide with 10.0?
> >>> (3) Or both?
> >>>
> >>> Best,
> >>>
> >>> Jason
> >>>
> >>> On Mon, Oct 31, 2022 at 5:04 PM Jan Høydahl <ja...@cominvent.com>
> wrote:
> >>>>
> >>>> Thanks for a thorough SIP.
> >>>>
> >>>> Wrt deprecation plan, could we not have "v2-API-Complete" in e.g. 9.5
> (and deprecate v1). Then we wait until 10.0 with "v2-API-used-internally",
> and 11.0 for removing v1. Say we release 10.0 in March 2023, then the new
> main will be 11.0 and we can already remove v1 in main.
> >>>>
> >>>> Looking forward to code generating SolrJ classes. And perhaps
> community members actively using some other prog.language will be empowered
> to auto generate 90% of such clients.
> >>>>
> >>>> Jan
> >>>>
> >>>>> 31. okt. 2022 kl. 21:23 skrev Jason Gerlowski <gerlowskija@gmail.com
> >:
> >>>>>
> >>>>> Hey all,
> >>>>>
> >>>>> This morning I published SIP-16, which proposes the changes necessary
> >>>>> to "finish" (i.e. plug coverage gaps and polish) Solr's v2 APIs and a
> >>>>> path to deprecating Solr's v1 APIs.
> >>>>>
> >>>>> The SIP can be found here:
> >>>>>
> https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation
> >>>>>
> >>>>> Please read the SIP description and come back here for discussion.
> As
> >>>>> the discussion progresses we will update the SIP page with any
> >>>>> outcomes and eventually move things to a VOTE (or lazy consensus).
> >>>>>
> >>>>> Looking forward to hearing your feedback!
> >>>>>
> >>>>> 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
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
-----------------------------------------------------
Noble Paul
Re: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by Jan Høydahl <ja...@cominvent.com>.
I'm not against a more aggressive plan, i.e. remove v1 in 10.0 - users will just have to stay longer on 9.x if they don't want to change their apps.
My only worry there is that the Solr 10.0 release MAY happen already in Q2/Q3 2023, and that leaves just a few months preparation time for the entire ecosystem to change (other language clients, crawlers, Blacklight etc).
Let's hear other voices on this too.
Jan
> 7. nov. 2022 kl. 13:41 skrev Jason Gerlowski <ge...@gmail.com>:
>
> Hi Jan,
>
> I guess I'd be a bit uncomfortable with deprecating v1 until v2 has
> had some decent dog-fooding. That's probably why the SIP suggests
> that deprecation coincide with "v2-used-internally": because the
> earlier "v2-complete" doesn't mean that anything even uses the v2 API
> yet. But that's just my two cents: if there's consensus that we have
> enough confidence in v2, or that it'd be valuable to get the
> deprecation warning out there earlier, then I can live with that.
>
> On your second point, I'm a little leery of tying "v2-complete",
> "v2-used-internally", and "eventual removal" to any particular
> releases - mostly because the timing around our releases has been
> somewhat unpredictable. I certainly agree that v1 removal has to
> happen on a major-version boundary, and if 10.0 comes around quickly,
> then the timeline you suggest seems pretty plausible. But 10.0 might
> take much longer (9.0 took 3 years after all), in which case it seems
> reasonable to me that v1 could be removed for 10.0 if all the
> prerequisites happen early enough in the 9.x line. I guess I'm
> worried about a scenario where both 10.x and 11.x are long release
> lines, and we end up supporting v1 forever. Any thoughts on that?
>
> Best,
>
> Jason
>
> On Sun, Nov 6, 2022 at 3:04 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>
>> Both.
>>
>> 9x: v2 complete, deprecate v1 (and adding some deprecation noise to logs)
>> 10.0 Switch to using v2 internally
>> 11.0 Remove v1
>>
>> Jan
>>
>>> 4. nov. 2022 kl. 16:25 skrev Jason Gerlowski <ge...@gmail.com>:
>>>
>>> Hi Jan,
>>>
>>> Just trying to make sure I understand your suggestion. Are you suggesting:
>>>
>>> (1) that we announce v1 as deprecated at "V2-API-Complete" (instead of
>>> the later "v2-API-used-internally")? Or...
>>> (2) that we plan "v2-API-used-internally" to coincide with 10.0?
>>> (3) Or both?
>>>
>>> Best,
>>>
>>> Jason
>>>
>>> On Mon, Oct 31, 2022 at 5:04 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>>>
>>>> Thanks for a thorough SIP.
>>>>
>>>> Wrt deprecation plan, could we not have "v2-API-Complete" in e.g. 9.5 (and deprecate v1). Then we wait until 10.0 with "v2-API-used-internally", and 11.0 for removing v1. Say we release 10.0 in March 2023, then the new main will be 11.0 and we can already remove v1 in main.
>>>>
>>>> Looking forward to code generating SolrJ classes. And perhaps community members actively using some other prog.language will be empowered to auto generate 90% of such clients.
>>>>
>>>> Jan
>>>>
>>>>> 31. okt. 2022 kl. 21:23 skrev Jason Gerlowski <ge...@gmail.com>:
>>>>>
>>>>> Hey all,
>>>>>
>>>>> This morning I published SIP-16, which proposes the changes necessary
>>>>> to "finish" (i.e. plug coverage gaps and polish) Solr's v2 APIs and a
>>>>> path to deprecating Solr's v1 APIs.
>>>>>
>>>>> The SIP can be found here:
>>>>> https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation
>>>>>
>>>>> Please read the SIP description and come back here for discussion. As
>>>>> the discussion progresses we will update the SIP page with any
>>>>> outcomes and eventually move things to a VOTE (or lazy consensus).
>>>>>
>>>>> Looking forward to hearing your feedback!
>>>>>
>>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by Jason Gerlowski <ge...@gmail.com>.
Hi Jan,
I guess I'd be a bit uncomfortable with deprecating v1 until v2 has
had some decent dog-fooding. That's probably why the SIP suggests
that deprecation coincide with "v2-used-internally": because the
earlier "v2-complete" doesn't mean that anything even uses the v2 API
yet. But that's just my two cents: if there's consensus that we have
enough confidence in v2, or that it'd be valuable to get the
deprecation warning out there earlier, then I can live with that.
On your second point, I'm a little leery of tying "v2-complete",
"v2-used-internally", and "eventual removal" to any particular
releases - mostly because the timing around our releases has been
somewhat unpredictable. I certainly agree that v1 removal has to
happen on a major-version boundary, and if 10.0 comes around quickly,
then the timeline you suggest seems pretty plausible. But 10.0 might
take much longer (9.0 took 3 years after all), in which case it seems
reasonable to me that v1 could be removed for 10.0 if all the
prerequisites happen early enough in the 9.x line. I guess I'm
worried about a scenario where both 10.x and 11.x are long release
lines, and we end up supporting v1 forever. Any thoughts on that?
Best,
Jason
On Sun, Nov 6, 2022 at 3:04 PM Jan Høydahl <ja...@cominvent.com> wrote:
>
> Both.
>
> 9x: v2 complete, deprecate v1 (and adding some deprecation noise to logs)
> 10.0 Switch to using v2 internally
> 11.0 Remove v1
>
> Jan
>
> > 4. nov. 2022 kl. 16:25 skrev Jason Gerlowski <ge...@gmail.com>:
> >
> > Hi Jan,
> >
> > Just trying to make sure I understand your suggestion. Are you suggesting:
> >
> > (1) that we announce v1 as deprecated at "V2-API-Complete" (instead of
> > the later "v2-API-used-internally")? Or...
> > (2) that we plan "v2-API-used-internally" to coincide with 10.0?
> > (3) Or both?
> >
> > Best,
> >
> > Jason
> >
> > On Mon, Oct 31, 2022 at 5:04 PM Jan Høydahl <ja...@cominvent.com> wrote:
> >>
> >> Thanks for a thorough SIP.
> >>
> >> Wrt deprecation plan, could we not have "v2-API-Complete" in e.g. 9.5 (and deprecate v1). Then we wait until 10.0 with "v2-API-used-internally", and 11.0 for removing v1. Say we release 10.0 in March 2023, then the new main will be 11.0 and we can already remove v1 in main.
> >>
> >> Looking forward to code generating SolrJ classes. And perhaps community members actively using some other prog.language will be empowered to auto generate 90% of such clients.
> >>
> >> Jan
> >>
> >>> 31. okt. 2022 kl. 21:23 skrev Jason Gerlowski <ge...@gmail.com>:
> >>>
> >>> Hey all,
> >>>
> >>> This morning I published SIP-16, which proposes the changes necessary
> >>> to "finish" (i.e. plug coverage gaps and polish) Solr's v2 APIs and a
> >>> path to deprecating Solr's v1 APIs.
> >>>
> >>> The SIP can be found here:
> >>> https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation
> >>>
> >>> Please read the SIP description and come back here for discussion. As
> >>> the discussion progresses we will update the SIP page with any
> >>> outcomes and eventually move things to a VOTE (or lazy consensus).
> >>>
> >>> Looking forward to hearing your feedback!
> >>>
> >>> 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
> >>
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by Jan Høydahl <ja...@cominvent.com>.
Both.
9x: v2 complete, deprecate v1 (and adding some deprecation noise to logs)
10.0 Switch to using v2 internally
11.0 Remove v1
Jan
> 4. nov. 2022 kl. 16:25 skrev Jason Gerlowski <ge...@gmail.com>:
>
> Hi Jan,
>
> Just trying to make sure I understand your suggestion. Are you suggesting:
>
> (1) that we announce v1 as deprecated at "V2-API-Complete" (instead of
> the later "v2-API-used-internally")? Or...
> (2) that we plan "v2-API-used-internally" to coincide with 10.0?
> (3) Or both?
>
> Best,
>
> Jason
>
> On Mon, Oct 31, 2022 at 5:04 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>
>> Thanks for a thorough SIP.
>>
>> Wrt deprecation plan, could we not have "v2-API-Complete" in e.g. 9.5 (and deprecate v1). Then we wait until 10.0 with "v2-API-used-internally", and 11.0 for removing v1. Say we release 10.0 in March 2023, then the new main will be 11.0 and we can already remove v1 in main.
>>
>> Looking forward to code generating SolrJ classes. And perhaps community members actively using some other prog.language will be empowered to auto generate 90% of such clients.
>>
>> Jan
>>
>>> 31. okt. 2022 kl. 21:23 skrev Jason Gerlowski <ge...@gmail.com>:
>>>
>>> Hey all,
>>>
>>> This morning I published SIP-16, which proposes the changes necessary
>>> to "finish" (i.e. plug coverage gaps and polish) Solr's v2 APIs and a
>>> path to deprecating Solr's v1 APIs.
>>>
>>> The SIP can be found here:
>>> https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation
>>>
>>> Please read the SIP description and come back here for discussion. As
>>> the discussion progresses we will update the SIP page with any
>>> outcomes and eventually move things to a VOTE (or lazy consensus).
>>>
>>> Looking forward to hearing your feedback!
>>>
>>> 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
>>
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by Jason Gerlowski <ge...@gmail.com>.
Hi Jan,
Just trying to make sure I understand your suggestion. Are you suggesting:
(1) that we announce v1 as deprecated at "V2-API-Complete" (instead of
the later "v2-API-used-internally")? Or...
(2) that we plan "v2-API-used-internally" to coincide with 10.0?
(3) Or both?
Best,
Jason
On Mon, Oct 31, 2022 at 5:04 PM Jan Høydahl <ja...@cominvent.com> wrote:
>
> Thanks for a thorough SIP.
>
> Wrt deprecation plan, could we not have "v2-API-Complete" in e.g. 9.5 (and deprecate v1). Then we wait until 10.0 with "v2-API-used-internally", and 11.0 for removing v1. Say we release 10.0 in March 2023, then the new main will be 11.0 and we can already remove v1 in main.
>
> Looking forward to code generating SolrJ classes. And perhaps community members actively using some other prog.language will be empowered to auto generate 90% of such clients.
>
> Jan
>
> > 31. okt. 2022 kl. 21:23 skrev Jason Gerlowski <ge...@gmail.com>:
> >
> > Hey all,
> >
> > This morning I published SIP-16, which proposes the changes necessary
> > to "finish" (i.e. plug coverage gaps and polish) Solr's v2 APIs and a
> > path to deprecating Solr's v1 APIs.
> >
> > The SIP can be found here:
> > https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation
> >
> > Please read the SIP description and come back here for discussion. As
> > the discussion progresses we will update the SIP page with any
> > outcomes and eventually move things to a VOTE (or lazy consensus).
> >
> > Looking forward to hearing your feedback!
> >
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by Jan Høydahl <ja...@cominvent.com>.
Thanks for a thorough SIP.
Wrt deprecation plan, could we not have "v2-API-Complete" in e.g. 9.5 (and deprecate v1). Then we wait until 10.0 with "v2-API-used-internally", and 11.0 for removing v1. Say we release 10.0 in March 2023, then the new main will be 11.0 and we can already remove v1 in main.
Looking forward to code generating SolrJ classes. And perhaps community members actively using some other prog.language will be empowered to auto generate 90% of such clients.
Jan
> 31. okt. 2022 kl. 21:23 skrev Jason Gerlowski <ge...@gmail.com>:
>
> Hey all,
>
> This morning I published SIP-16, which proposes the changes necessary
> to "finish" (i.e. plug coverage gaps and polish) Solr's v2 APIs and a
> path to deprecating Solr's v1 APIs.
>
> The SIP can be found here:
> https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation
>
> Please read the SIP description and come back here for discussion. As
> the discussion progresses we will update the SIP page with any
> outcomes and eventually move things to a VOTE (or lazy consensus).
>
> Looking forward to hearing your feedback!
>
> 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: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by Jason Gerlowski <ge...@gmail.com>.
Hey Colvin,
Awesome to hear you're making progress on the v2 API integration
test(s). Thanks again for taking that up - it'll be a huge
improvement! Feel free to be aggressive about tagging me on the PR
when it's ready for review, if it seems like I missed it.
> From a consumer POV what I have noticed is that the validation of the
> requests is slightly brutal, in that invalid input (missing fields, object
> instead of an array etc) leads to a 500 response rather than a 400
That's definitely not the intention - can you file a JIRA describing a
particular case, and we can continue the discussion there?
Best,
Jason
On Fri, Feb 14, 2025 at 10:14 AM Jason Gerlowski <ge...@gmail.com> wrote:
>
> Hey Christos,
>
> Sorry for the delay - I don't know the logging functionality all that
> well and had to do some digging before I could reply. Replies below
> inline:
>
> > Let me know if I should create individual threads for such grouped questions
>
> If I put myself in the shoes of someone coming to this thread to
> understand the v2 API design and progress as a whole, then a lot of
> this discussion would be "noise" to them. So +1 to using a different
> thread next time. But let's continue discussion here to minimize
> overhead - if you have any followups, we can break into a separate
> thread at that point.
>
> > I assume they are specific to the node currently connected, since we have "/node" in the URL path.
>
> This has historically been true, but apparently it changed several
> years back as a part of SOLR-15011, which has led to a gap between
> what the v1 and v2 APIs support. In terms of changing log values, the
> v1 API can update the log-level either globally or "just" on the
> receiving node based on the value of a "nodes" flag param. (This
> behavior only works in SolrCloud mode - the "nodes" parameter is
> ignored when running in standalone mode) To be more explicit:
>
> Update all nodes
> - v1: GET /solr/admin/info/logging?set=className:LEVEL&nodes=all
> - v2: (Unsupported)
>
> Update Single Node
> - v1: GET /solr/admin/info/logging?set=className:LEVEL
> - v2: PUT /api/node/logging/levels [{"className": "LEVEL"}]
>
> We should remedy this functionality gap, and probably change the v2
> API path to reflect the changed behavior.
>
> > Can each node configure only one log watcher (like Log4j2) at a time, or ...
>
> Yep, Solr currently only supports a single watcher at a time. Solr
> creates a single "LogWatcher" instance (for either JUL or Log4j) at
> boot time, and then reuses that for the life of the process afaict.
>
> > The class LogLevelInfo does not provide much information about the fields
>
> You're right - it could really be better documented.
>
> The "name" parameter represents the name of the logger in question, so
> I suspect it will always be non-null and non-empty. Looking at a few
> of the LogWatcher implementations, it looks like "level" can be null
> when set=false. These would be great things to document in
> @JsonProperty and OpenAPI annotations, if anyone reading is interested
> in helping fill in that gap?
>
> > In LogMessagesResponse, the "docs" field is currently just an object and has an open TODO. Who is currently defining the object of "docs"?
>
> Gah - I forgot about this. The "docs" field is a "SolrDocumentList" -
> the same type that Solr uses to return search results. But
> SolrDocumentList as a Java class lives in a different gradle module
> and itself relies on other utilities/types that we don't want to pull
> into the 'api' module where LogMessageResponse lives. It's a solvable
> problem with some refactoring, just not one that I (or anyone else)
> has gotten to yet. Again - a great place to jump in if any interested
> readers want to get their feet wet in the v2 API code!
>
> In the code, the "docs" field gets populated by the retval of
> "LogWatcher.getHistory(...)"
>
> Hope that helps clear up some of your questions. Happy to clarify if
> you have any followups (but let's move that to a separate thread).
>
> Best,
>
> Jason
>
>
> On Tue, Feb 11, 2025 at 4:30 AM Colvin Cowie <co...@gmail.com> wrote:
> >
> > Just to say, I've been writing a smoke test for the v2 APIs when I've had a
> > spare hour, I've done about half of it
> > https://github.com/apache/solr/pull/3023/files
> > <https://github.com/apache/solr/pull/3023/files#diff-549531110b26fa08a870f1853351abad4808116ff4258b5226358d6a5073dadb>
> > I've found three broken endpoints so far; hopefully I'll finish writing the
> > test this weekend and see if there's any more.
> >
> > From a consumer POV what I have noticed is that the validation of the
> > requests is slightly brutal, in that invalid input (missing fields, object
> > instead of an array etc) leads to a 500 response rather than a 400.
> > It would be good to distinguish bad request errors from backend errors. A *nice
> > to have*, would be to return the error in the response (e.g. using RFC 7807
> > / RFC 9457 error responses), so that the client author doesn't have to go
> > to the server log when they get it wrong.
> >
> >
> > On Tue, 11 Feb 2025 at 02:13, David Smiley <ds...@gmail.com> wrote:
> >
> > > (An aside: discussion around a particular endpoint or even category of
> > > endpoints deserves its own thread IMO)
> > >
> > > > On Feb 10, 2025, at 4:40 PM, Christos Malliaridis <
> > > malliaridis@apache.org> wrote:
> > > > - If this assumption is correct, can one update the log level of all
> > > nodes with a single request?
> > >
> > > I can say Solr supports this, _at least_ in the V1 API, as I was involved
> > > as a reviewer.
> > > ---------------------------------------------------------------------
> > > 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: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by Jason Gerlowski <ge...@gmail.com>.
Hey Christos,
Sorry for the delay - I don't know the logging functionality all that
well and had to do some digging before I could reply. Replies below
inline:
> Let me know if I should create individual threads for such grouped questions
If I put myself in the shoes of someone coming to this thread to
understand the v2 API design and progress as a whole, then a lot of
this discussion would be "noise" to them. So +1 to using a different
thread next time. But let's continue discussion here to minimize
overhead - if you have any followups, we can break into a separate
thread at that point.
> I assume they are specific to the node currently connected, since we have "/node" in the URL path.
This has historically been true, but apparently it changed several
years back as a part of SOLR-15011, which has led to a gap between
what the v1 and v2 APIs support. In terms of changing log values, the
v1 API can update the log-level either globally or "just" on the
receiving node based on the value of a "nodes" flag param. (This
behavior only works in SolrCloud mode - the "nodes" parameter is
ignored when running in standalone mode) To be more explicit:
Update all nodes
- v1: GET /solr/admin/info/logging?set=className:LEVEL&nodes=all
- v2: (Unsupported)
Update Single Node
- v1: GET /solr/admin/info/logging?set=className:LEVEL
- v2: PUT /api/node/logging/levels [{"className": "LEVEL"}]
We should remedy this functionality gap, and probably change the v2
API path to reflect the changed behavior.
> Can each node configure only one log watcher (like Log4j2) at a time, or ...
Yep, Solr currently only supports a single watcher at a time. Solr
creates a single "LogWatcher" instance (for either JUL or Log4j) at
boot time, and then reuses that for the life of the process afaict.
> The class LogLevelInfo does not provide much information about the fields
You're right - it could really be better documented.
The "name" parameter represents the name of the logger in question, so
I suspect it will always be non-null and non-empty. Looking at a few
of the LogWatcher implementations, it looks like "level" can be null
when set=false. These would be great things to document in
@JsonProperty and OpenAPI annotations, if anyone reading is interested
in helping fill in that gap?
> In LogMessagesResponse, the "docs" field is currently just an object and has an open TODO. Who is currently defining the object of "docs"?
Gah - I forgot about this. The "docs" field is a "SolrDocumentList" -
the same type that Solr uses to return search results. But
SolrDocumentList as a Java class lives in a different gradle module
and itself relies on other utilities/types that we don't want to pull
into the 'api' module where LogMessageResponse lives. It's a solvable
problem with some refactoring, just not one that I (or anyone else)
has gotten to yet. Again - a great place to jump in if any interested
readers want to get their feet wet in the v2 API code!
In the code, the "docs" field gets populated by the retval of
"LogWatcher.getHistory(...)"
Hope that helps clear up some of your questions. Happy to clarify if
you have any followups (but let's move that to a separate thread).
Best,
Jason
On Tue, Feb 11, 2025 at 4:30 AM Colvin Cowie <co...@gmail.com> wrote:
>
> Just to say, I've been writing a smoke test for the v2 APIs when I've had a
> spare hour, I've done about half of it
> https://github.com/apache/solr/pull/3023/files
> <https://github.com/apache/solr/pull/3023/files#diff-549531110b26fa08a870f1853351abad4808116ff4258b5226358d6a5073dadb>
> I've found three broken endpoints so far; hopefully I'll finish writing the
> test this weekend and see if there's any more.
>
> From a consumer POV what I have noticed is that the validation of the
> requests is slightly brutal, in that invalid input (missing fields, object
> instead of an array etc) leads to a 500 response rather than a 400.
> It would be good to distinguish bad request errors from backend errors. A *nice
> to have*, would be to return the error in the response (e.g. using RFC 7807
> / RFC 9457 error responses), so that the client author doesn't have to go
> to the server log when they get it wrong.
>
>
> On Tue, 11 Feb 2025 at 02:13, David Smiley <ds...@gmail.com> wrote:
>
> > (An aside: discussion around a particular endpoint or even category of
> > endpoints deserves its own thread IMO)
> >
> > > On Feb 10, 2025, at 4:40 PM, Christos Malliaridis <
> > malliaridis@apache.org> wrote:
> > > - If this assumption is correct, can one update the log level of all
> > nodes with a single request?
> >
> > I can say Solr supports this, _at least_ in the V1 API, as I was involved
> > as a reviewer.
> > ---------------------------------------------------------------------
> > 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: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by Colvin Cowie <co...@gmail.com>.
Just to say, I've been writing a smoke test for the v2 APIs when I've had a
spare hour, I've done about half of it
https://github.com/apache/solr/pull/3023/files
<https://github.com/apache/solr/pull/3023/files#diff-549531110b26fa08a870f1853351abad4808116ff4258b5226358d6a5073dadb>
I've found three broken endpoints so far; hopefully I'll finish writing the
test this weekend and see if there's any more.
From a consumer POV what I have noticed is that the validation of the
requests is slightly brutal, in that invalid input (missing fields, object
instead of an array etc) leads to a 500 response rather than a 400.
It would be good to distinguish bad request errors from backend errors. A *nice
to have*, would be to return the error in the response (e.g. using RFC 7807
/ RFC 9457 error responses), so that the client author doesn't have to go
to the server log when they get it wrong.
On Tue, 11 Feb 2025 at 02:13, David Smiley <ds...@gmail.com> wrote:
> (An aside: discussion around a particular endpoint or even category of
> endpoints deserves its own thread IMO)
>
> > On Feb 10, 2025, at 4:40 PM, Christos Malliaridis <
> malliaridis@apache.org> wrote:
> > - If this assumption is correct, can one update the log level of all
> nodes with a single request?
>
> I can say Solr supports this, _at least_ in the V1 API, as I was involved
> as a reviewer.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by David Smiley <ds...@gmail.com>.
(An aside: discussion around a particular endpoint or even category of endpoints deserves its own thread IMO)
> On Feb 10, 2025, at 4:40 PM, Christos Malliaridis <ma...@apache.org> wrote:
> - If this assumption is correct, can one update the log level of all nodes with a single request?
I can say Solr supports this, _at least_ in the V1 API, as I was involved as a reviewer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by David Smiley <ds...@gmail.com>.
(An aside: discussion around a particular endpoint or even category of endpoints deserves its own thread IMO)
> On Feb 10, 2025, at 4:40 PM, Christos Malliaridis <ma...@apache.org> wrote:
> - If this assumption is correct, can one update the log level of all nodes with a single request?
I can say Solr supports this, _at least_ in the V1 API, as I was involved as a reviewer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] SIP-16: Polish and Prepare v2 APIs for v1 Deprecation
Posted by Christos Malliaridis <ma...@apache.org>.
I am very pleased by the progress we achieved in this topic so far, and I would like to add some input from the consumers' perspective.
With the start of the new Admin UI development (SIP-7), we now have an additional source for evaluating the v2 API and polish it based on additional scenarios. While the new UI is far from finished, I have some questions about the v2 API capabilities.
Right now I am focusing on the logging part (see https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=14-3933&t=39r2LtHZr4zMGLnu-1 for reference), so the endpoints I am referring to below are related to anything from /api/node/logging/*.
From how I understand the new endpoints, I assume they are specific to the node currently connected, since we have "/node" in the URL path.
- If this assumption is correct, can one update the log level of all nodes with a single request?
- If not, how would one update all nodes / each node?
- If the assumption is wrong, would interacting with the API endpoint always affect all nodes?
- If all nodes are always affected, does that mean that the log configurations are identical (including the current log watcher, log levels and log history received)?
Can each node configure only one log watcher (like Log4j2) at a time, or is there an option to configure more than one log watcher and configure them individually (since I believe the log levels may differ depening on the watcher)?
- If only one log watcher is possible, I think the API in this part would only require a bit of documentation about the returned objects (e.g. LogLevelInfo).
- If more than one log watcher are possible, then it seems to me that the current API does not provide any option to configure each log watcher individually or get data from a specific log watcher.
The class LogLevelInfo does not provide much information about the fields. So I am wondering,
- is "LogLevelInfo#level" always nullable / not nullable, regardless of the value of "LogLevelInfo#set"?
- can "LogLevelInfo#name" be any string and is it always not null and not empty?
In LogMessagesResponse, the "docs" field is currently just an object and has an open TODO. Who is currently defining the object of "docs"?
I may get into a bit too much detail for this thread, but I think having a single thread for all the API-related questions would be beneficial? Let me know if I should create individual threads for such grouped questions. :)
Best,
Christos
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org