Re: How to enable basic auth in tests?

[Jason Gerlowski]

The code snippet you included is the main one I've seen (in
SolrCloudTestCase-derived classes at least).  It's fairly simple with
just that one line, though I imagine most of the complexity comes in
with making sure created clients have a corresponding auth setup...

Was that (i.e. client creation) what you were hoping to find a
streamlined approach for, or was there another aspect of this you had
in mind?

Jason

On Tue, Sep 26, 2023 at 9:13 AM Eric Pugh
 wrote:
>
> Has anyone found a good pattern for enabling basic auth in our tests?   I 
> suspect that some number of tests are basically “Does this work With and 
> Without Basic Auth”, versus being specific to the implementation of 
> BasicAuth.   I found TestPullReplicaWithAuth.java, and it has some code to 
> create a custom security.json and then load it using:
>
>configureCluster(2)
> .addConfig("conf", configset("cloud-minimal"))
> .withSecurityJson(SECURITY_JSON)
> .configure();
>
> Is there any simpler option?  Could I have a rule that says I want basicAuth 
> enabled for my test?
>
> Eric
>
>
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com  
> | My Free/Busy 
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
> 
> This e-mail and all contents, including attachments, is considered to be 
> Company Confidential unless explicitly stated otherwise, regardless of 
> whether attachments are marked as such.
>

-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: Ideas for Grabbing Json from URL in our Unit Tests and Code?

[Jason Gerlowski]

> often the reason we are grabbing JSON from some random URL is because we 
> don’t have SolrJ support for that specific API

I know of some tests that intentionally _don't_ use SolrJ because
they're trying to validate some aspect of the form of the API.  i.e.
The test isn't validating the API functionality so much as it's
validating that the HTTP path, parameter names, etc. are all what they
should be.  So IMO there are at least a few valid usecases for the
"grabbing JSON from some random URL" approach.

But in general I agree with your theory above that a lot of this is
driven by lack of support for particular APIs in SolrJ.  We put a lot
of work into our SolrJ client, that's what we should be dogfooding
internally (and in our tests).  If we're not doing that in some places
because there's no SolrJ class for a particular API, then that seems
like the thing to fix IMO.

SOLR-16825 will help with closing these gaps in SolrJ as time
progresses by ensuring that all v2 APIs at least are covered in SolrJ.
It'd be awesome to get some dogfooding on these experimental generated
classes, as long as we're OK with them continuing to evolve a bit over
time.

On Mon, Oct 2, 2023 at 2:35 PM Eric Pugh
 wrote:
>
> I had another thought which is that often the reason we are grabbing JSON 
> from some random URL is because we don’t have SolrJ support for that specific 
> API.   However, with the upcoming V2 api’s and the code generated Java client 
> objects, maybe we could start using them in our tests.
>
> This would let us use Java code with all the type support in a lot of places. 
>   Another reason to push forward on the V2 API’s!!!
>
>
> Eric
>
>
> > On Sep 29, 2023, at 10:46 AM, Eric Pugh  
> > wrote:
> >
> > In SOLR-14496 for adding basic auth to our CLI, I ran again into “I need to 
> > call an end point that spits back JSON and do something with it”.
> >
> > Specifically, you can see this rather convoluted method 
> > https://github.com/apache/solr/pull/1954/files#diff-9cf9bffde79b0e6e23224cd3240c4a2b281ba91eed9ad1fb050759b2018f4f3c
> >   testForResponseElement.
> >
> > It is copied from TestSolrConfigHandler.testForResponseElement but then 
> > reworked to actually use the ApiTool under the covers.   Good?  Bad?  Dunno.
> >
> > I feel like through the code base, both in the code and tests, multiple 
> > places we need to do this, and they each work a bit different.   Including 
> > my own flavour that I just added using the ApiTool!
> >
> > Are there any strong opinions on the “right way” that exist out there that 
> > we could try and standardize around?  I’d be willing to invest in the 
> > migration work if we had a “right way” ;-).
> >
> > Eric
> > ___
> > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> > http://www.opensourceconnections.com 
> >  | My Free/Busy 
> > 
> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
> > 
> > This e-mail and all contents, including attachments, is considered to be 
> > Company Confidential unless explicitly stated otherwise, regardless of 
> > whether attachments are marked as such.
> >
>
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com  
> | My Free/Busy 
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
> 
> This e-mail and all contents, including attachments, is considered to be 
> Company Confidential unless explicitly stated otherwise, regardless of 
> whether attachments are marked as such.
>

-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: New branch and feature freeze for Solr 9.4.0

[Alex Deparvu]

Quick update, we are blocker free. Both issues have been resolved and as
far as I can see there is no pending issue for 9.4 anymore.

best
alex


On Tue, Oct 3, 2023 at 2:45 PM Walter Underwood 
wrote:

> I think this is missing a some words:
>
> "A new Always-On trace id generator and the rid parameter is being
> deprecated”
>
> Maybe “…generator has been added and…”? As it stands, it looks like the
> new trace id generator is being deprecated.
>
> The circuit breaker descriptions are accurate, but probably do not need to
> be capitalized. In general, there seem to be extra capitalizations, like
> “Always-On” and “Backup, Restore, and Split”.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> > On Oct 3, 2023, at 2:00 PM, Alex Deparvu  wrote:
> >
> > Please update the draft release notes if you have any suggestions:
> >
> > https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote9_4_0
> >
> > best,
> > alex
> >
> >
> >
> > On Tue, Oct 3, 2023 at 11:26 AM Alex Deparvu 
> wrote:
> >
> >> NOTICE:
> >>
> >> Branch branch_9_4 has been cut and versions updated to 9.5 on stable the
> >> branch.
> >>
> >> Please observe the normal rules:
> >>
> >> * No new features may be committed to the branch.
> >> * Documentation patches, build patches and serious bug fixes may be
> >>  committed to the branch. However, you should submit all patches you
> >>  want to commit to Jira first to give others the chance to review
> >>  and possibly vote against the patch. Keep in mind that it is our
> >>  main intention to keep the branch as stable as possible.
> >> * All patches that are intended for the branch should first be committed
> >>  to the unstable branch, merged into the stable branch, and then into
> >>  the current release branch.
> >> * Normal unstable and stable branch development may continue as usual.
> >>  However, if you plan to commit a big change to the unstable branch
> >>  while the branch feature freeze is in effect, think twice: can't the
> >>  addition wait a couple more days? Merges of bug fixes into the branch
> >>  may become more difficult.
> >> * Only Jira issues with Fix version 9.4 and priority "Blocker" will
> delay
> >>  a release candidate build.
> >>
>
>

Re: New branch and feature freeze for Solr 9.4.0

[Ishan Chattopadhyaya]

Can you please suggest when you're planning to spin the first RC? Are bug
fixes still allowed into the release branch until then?

On Wed, 4 Oct, 2023, 9:58 pm Alex Deparvu,  wrote:

> Quick update, we are blocker free. Both issues have been resolved and as
> far as I can see there is no pending issue for 9.4 anymore.
>
> best
> alex
>
>
> On Tue, Oct 3, 2023 at 2:45 PM Walter Underwood 
> wrote:
>
> > I think this is missing a some words:
> >
> > "A new Always-On trace id generator and the rid parameter is being
> > deprecated”
> >
> > Maybe “…generator has been added and…”? As it stands, it looks like the
> > new trace id generator is being deprecated.
> >
> > The circuit breaker descriptions are accurate, but probably do not need
> to
> > be capitalized. In general, there seem to be extra capitalizations, like
> > “Always-On” and “Backup, Restore, and Split”.
> >
> > wunder
> > Walter Underwood
> > wun...@wunderwood.org
> > http://observer.wunderwood.org/  (my blog)
> >
> > > On Oct 3, 2023, at 2:00 PM, Alex Deparvu  wrote:
> > >
> > > Please update the draft release notes if you have any suggestions:
> > >
> > > https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote9_4_0
> > >
> > > best,
> > > alex
> > >
> > >
> > >
> > > On Tue, Oct 3, 2023 at 11:26 AM Alex Deparvu 
> > wrote:
> > >
> > >> NOTICE:
> > >>
> > >> Branch branch_9_4 has been cut and versions updated to 9.5 on stable
> the
> > >> branch.
> > >>
> > >> Please observe the normal rules:
> > >>
> > >> * No new features may be committed to the branch.
> > >> * Documentation patches, build patches and serious bug fixes may be
> > >>  committed to the branch. However, you should submit all patches you
> > >>  want to commit to Jira first to give others the chance to review
> > >>  and possibly vote against the patch. Keep in mind that it is our
> > >>  main intention to keep the branch as stable as possible.
> > >> * All patches that are intended for the branch should first be
> committed
> > >>  to the unstable branch, merged into the stable branch, and then into
> > >>  the current release branch.
> > >> * Normal unstable and stable branch development may continue as usual.
> > >>  However, if you plan to commit a big change to the unstable branch
> > >>  while the branch feature freeze is in effect, think twice: can't the
> > >>  addition wait a couple more days? Merges of bug fixes into the branch
> > >>  may become more difficult.
> > >> * Only Jira issues with Fix version 9.4 and priority "Blocker" will
> > delay
> > >>  a release candidate build.
> > >>
> >
> >
>

Re: New branch and feature freeze for Solr 9.4.0

[Alex Deparvu]

Hi.
Sorry, I should have made that clearer. I am planning the first RC for
tomorrow morning.

> Are bug fixes still allowed into the release branch until then?
Not really sure, maybe others can chime in? my guess is this can go in if
it is a blocker.

best,
alex



On Wed, Oct 4, 2023 at 9:45 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Can you please suggest when you're planning to spin the first RC? Are bug
> fixes still allowed into the release branch until then?
>
> On Wed, 4 Oct, 2023, 9:58 pm Alex Deparvu,  wrote:
>
> > Quick update, we are blocker free. Both issues have been resolved and as
> > far as I can see there is no pending issue for 9.4 anymore.
> >
> > best
> > alex
> >
> >
> > On Tue, Oct 3, 2023 at 2:45 PM Walter Underwood 
> > wrote:
> >
> > > I think this is missing a some words:
> > >
> > > "A new Always-On trace id generator and the rid parameter is being
> > > deprecated”
> > >
> > > Maybe “…generator has been added and…”? As it stands, it looks like the
> > > new trace id generator is being deprecated.
> > >
> > > The circuit breaker descriptions are accurate, but probably do not need
> > to
> > > be capitalized. In general, there seem to be extra capitalizations,
> like
> > > “Always-On” and “Backup, Restore, and Split”.
> > >
> > > wunder
> > > Walter Underwood
> > > wun...@wunderwood.org
> > > http://observer.wunderwood.org/  (my blog)
> > >
> > > > On Oct 3, 2023, at 2:00 PM, Alex Deparvu 
> wrote:
> > > >
> > > > Please update the draft release notes if you have any suggestions:
> > > >
> > > > https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote9_4_0
> > > >
> > > > best,
> > > > alex
> > > >
> > > >
> > > >
> > > > On Tue, Oct 3, 2023 at 11:26 AM Alex Deparvu 
> > > wrote:
> > > >
> > > >> NOTICE:
> > > >>
> > > >> Branch branch_9_4 has been cut and versions updated to 9.5 on stable
> > the
> > > >> branch.
> > > >>
> > > >> Please observe the normal rules:
> > > >>
> > > >> * No new features may be committed to the branch.
> > > >> * Documentation patches, build patches and serious bug fixes may be
> > > >>  committed to the branch. However, you should submit all patches you
> > > >>  want to commit to Jira first to give others the chance to review
> > > >>  and possibly vote against the patch. Keep in mind that it is our
> > > >>  main intention to keep the branch as stable as possible.
> > > >> * All patches that are intended for the branch should first be
> > committed
> > > >>  to the unstable branch, merged into the stable branch, and then
> into
> > > >>  the current release branch.
> > > >> * Normal unstable and stable branch development may continue as
> usual.
> > > >>  However, if you plan to commit a big change to the unstable branch
> > > >>  while the branch feature freeze is in effect, think twice: can't
> the
> > > >>  addition wait a couple more days? Merges of bug fixes into the
> branch
> > > >>  may become more difficult.
> > > >> * Only Jira issues with Fix version 9.4 and priority "Blocker" will
> > > delay
> > > >>  a release candidate build.
> > > >>
> > >
> > >
> >
>

Re: New branch and feature freeze for Solr 9.4.0

[Alex Deparvu]

I just reread my message and it was confusing. by "tomorrow morning" I mean
"I will give it another 24h starting now(ish)".

On Wed, Oct 4, 2023 at 10:35 AM Alex Deparvu  wrote:

> Hi.
> Sorry, I should have made that clearer. I am planning the first RC for
> tomorrow morning.
>
> > Are bug fixes still allowed into the release branch until then?
> Not really sure, maybe others can chime in? my guess is this can go in if
> it is a blocker.
>
> best,
> alex
>
>
>
> On Wed, Oct 4, 2023 at 9:45 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Can you please suggest when you're planning to spin the first RC? Are bug
>> fixes still allowed into the release branch until then?
>>
>> On Wed, 4 Oct, 2023, 9:58 pm Alex Deparvu,  wrote:
>>
>> > Quick update, we are blocker free. Both issues have been resolved and as
>> > far as I can see there is no pending issue for 9.4 anymore.
>> >
>> > best
>> > alex
>> >
>> >
>> > On Tue, Oct 3, 2023 at 2:45 PM Walter Underwood 
>> > wrote:
>> >
>> > > I think this is missing a some words:
>> > >
>> > > "A new Always-On trace id generator and the rid parameter is being
>> > > deprecated”
>> > >
>> > > Maybe “…generator has been added and…”? As it stands, it looks like
>> the
>> > > new trace id generator is being deprecated.
>> > >
>> > > The circuit breaker descriptions are accurate, but probably do not
>> need
>> > to
>> > > be capitalized. In general, there seem to be extra capitalizations,
>> like
>> > > “Always-On” and “Backup, Restore, and Split”.
>> > >
>> > > wunder
>> > > Walter Underwood
>> > > wun...@wunderwood.org
>> > > http://observer.wunderwood.org/  (my blog)
>> > >
>> > > > On Oct 3, 2023, at 2:00 PM, Alex Deparvu 
>> wrote:
>> > > >
>> > > > Please update the draft release notes if you have any suggestions:
>> > > >
>> > > > https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote9_4_0
>> > > >
>> > > > best,
>> > > > alex
>> > > >
>> > > >
>> > > >
>> > > > On Tue, Oct 3, 2023 at 11:26 AM Alex Deparvu 
>> > > wrote:
>> > > >
>> > > >> NOTICE:
>> > > >>
>> > > >> Branch branch_9_4 has been cut and versions updated to 9.5 on
>> stable
>> > the
>> > > >> branch.
>> > > >>
>> > > >> Please observe the normal rules:
>> > > >>
>> > > >> * No new features may be committed to the branch.
>> > > >> * Documentation patches, build patches and serious bug fixes may be
>> > > >>  committed to the branch. However, you should submit all patches
>> you
>> > > >>  want to commit to Jira first to give others the chance to review
>> > > >>  and possibly vote against the patch. Keep in mind that it is our
>> > > >>  main intention to keep the branch as stable as possible.
>> > > >> * All patches that are intended for the branch should first be
>> > committed
>> > > >>  to the unstable branch, merged into the stable branch, and then
>> into
>> > > >>  the current release branch.
>> > > >> * Normal unstable and stable branch development may continue as
>> usual.
>> > > >>  However, if you plan to commit a big change to the unstable branch
>> > > >>  while the branch feature freeze is in effect, think twice: can't
>> the
>> > > >>  addition wait a couple more days? Merges of bug fixes into the
>> branch
>> > > >>  may become more difficult.
>> > > >> * Only Jira issues with Fix version 9.4 and priority "Blocker" will
>> > > delay
>> > > >>  a release candidate build.
>> > > >>
>> > >
>> > >
>> >
>>
>