Just had time for the smoke tester this time, but +1 (binding)
Local end-to-end cluster test successfully run!
Successfully smoke tested the Solr Operator v0.6.0!
On Fri, Aug 12, 2022 at 5:26 AM Jason Gerlowski wrote:
>
> Hey all,
>
> Anyone else i
;
> > Tim, I added that issue as a blocker for the release.
> >
> > Jason, when going through the release steps you can move #436 to the next
> > milestone, as we won't get to it for this release.
> >
> > Thanks for volunteering Jason!
> >
> >
sounds good Jason ... I have some code in the works for issue 390 (pr
up soon) and will probably take a look at the other TLS related issues
over the next few days as well.
On Mon, Jul 11, 2022 at 11:27 AM Jason Gerlowski wrote:
>
> Hi all,
>
> solr-operator has had a good few bugfixes and improv
Thanks Mike for stepping up to do 8.11.2!
We recently uncovered some unexpected behavior with SQL LIKE queries
and I'd like to get a fix for
https://issues.apache.org/jira/browse/SOLR-16199 into 8.11.2. Will be
working on it today / tomorrow.
Cheers,
Tim
On Sun, May 15, 2022 at 5:49 PM Gus Heck
+1 (binding)
SUCCESS! [0:47:39.581876]
Just ran the smoke tester for this one, didn't have time to do any
other manual tests.
On Thu, May 5, 2022 at 1:47 PM Mike Drob wrote:
>
> [INFO] There was an issue with SOLR-16133 that caused the smoke tester to
> fail with gpg errors on macOS. That chan
+1 for option 2
Cheers,
Tim
On Fri, Apr 15, 2022 at 1:58 PM Gus Heck wrote:
>
> +1 for 2
>
> On Fri, Apr 15, 2022 at 1:47 PM David Smiley wrote:
>>
>> (no opinion) but thanks for driving this.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
+1 (binding)
SUCCESS! [0:48:43.626764]
Also built the Docker image and deployed via the Solr operator, tested
Prom exporter and Grafana dashboard, manually tested security screen
and schema designer. Also verified TLS (on K8s only)
Great work everyone!
Cheers,
Tim
On Thu, Apr 7, 2022 at 9:33 A
en for new solr clusters, not
> existing ones... Maybe I was overthinking this)
>
> I do hope that we can get v0.6.0 out in a month or so, because it should come
> with some very needed improvements.
>
> On Thu, Mar 17, 2022 at 12:00 PM Timothy Potter wrote:
>>
>>
+1 (binding)
Ran the smoke tester and deployed on Docker Desktop.
BTW: Is it possible to change the Solr version deployed from the Helm
chart to 8.11.1 w/o a respin of the RC? It's still deploying Solr 8.9
(easy enough to upgrade the Docker image if not)
Cheers,
Tim
On Wed, Mar 16, 2022 at 12:0
-1 for RC1 ... I wasn't able to run the smoke tester due to:
Check to make sure the manifests are up to date
diff --recursive config generated-check/config
diff --recursive config/crd/bases/solr.apache.org_solrbackups.yaml
generated-check/config/crd/bases/solr.apache.org_solrbackups.yaml
22,23c22,
It's close but I don't think it is quite ready for 1.0. However, I
would argue we've done a pretty good job at maintaining backwards
compat in the CRDs, which has added a lot of extra heavy lifting by
Houston at times.
Mainly the compat breaks were due to removing features added early in
the proje
Hi David,
I read your note about SOLR-14401 but not clear what you need from me?
Seems like you're renaming existing metrics and removing "distrib"
from handlers that don't support a distrib mode, seems right to me.
I actually haven't done much work on the metrics backend. For Grafana,
it's a JSO
The approach I've always used is: any change to the codebase needs a
JIRA. Any change a user would care about (in the most liberal sense)
needs a changes.txt entry. Refactoring that doesn't impact APIs (such
as changes to tests) doesn't need a changes.txt entry. In general it's
rare for me to make
I recently touched https related code, so this failure caught my eye
... So I beasted this failure in
org.apache.solr.handler.component.DistributedQueryComponentCustomSortTest.test
and don't think it's related to my recent https changes. Passed 29 out
of 30 ... and then the one that failed didn't r
+1 from me as well.
On Wed, Jan 19, 2022 at 7:47 PM Noble Paul wrote:
> +1
>
> I think every platform can support .tgz. This is one less artifact to
> upload during releases
>
> On Thu, Jan 20, 2022 at 11:38 AM Jan Høydahl
> wrote:
>
>> I don't want to do this without a bit more support than th
or
> >
> > * What went wrong:
> > Execution failed for task ':validateSourcePatterns'.
> >> Found 10 violations in source files (@author javadoc tag, svn keyword,
> tabs instead spaces).
> >
> > Jan
> >
> >> 6. jan. 2022 kl. 17:53 s
Thanks for the update Jan!
One of my PRs (sync'd with main) is now failing precommit with:
105 actionable tasks: 103 executed, 2 up-to-date
201FAILURE: Build failed with an exception.
202
203* Where:
204Script
'/home/runner/work/solr/solr/gradle/validation/solr.config-file-sanity.gradle'
line: 4
agreed! thanks for stepping up to be the RM Jan ;-)
On Tue, Dec 7, 2021 at 6:05 PM Jan Høydahl wrote:
>
> Hi,
>
> Solr has 13 bug fixes lined up in branch_8_11 already. Lucene has no changes.
> Now that Lucene 9.0 is out the door (congrats!), let's do the 8.11.1 release.
>
> I volunteer as RM and
Why do we keep talking about Restlet here? Restlet is a stale (at
best) project, so not sure why it keeps coming up in a discussion
about modernizing our API? Integration with it in Solr was introduced
nearly 10 years ago, time to move on and stop using that as an excuse
to block adoption of other
https://ci-builds.apache.org/job/Solr/job/Solr-Check-main/2018/testReport/junit/org.apache.solr.security/BaseTestRuleBasedAuthorizationPlugin/testBasicPermissions/
Also, see: http://fucit.org/solr-jenkins-reports/suspicious-failure-report.html
>From the failure, it looks like it's related to the
Agree it should be fixed but don't think we should rush out an 8.11.1
for this given 1) you can only read the file from that screen, there's
no support for editing files (which would be a useful feature), 2) you
can still read the files from the Cloud panel (cloud -> tree ->
configs ...)
Tim
On T
Thanks Houston! Looks like a great release
+1 (binding)
Smoketester passed and also ran through a number of tests with EKS and
Docker Desktop K8s!
Cheers,
Tim
On Thu, Nov 11, 2021 at 3:27 PM Houston Putman wrote:
>
> From first RC thread:
>
> Tim was very kind and created an 8.11.0 RC1 Solr do
gt;>>> the relevant configs should in principle be accessible from ZK whether
>>>>>>> or not there's a core for a given collection on a given node).
>>>>>>>
>>>>>>> Considering the above, and especially given Ishan that you
d carefully we could still allow that as “bulk” syntax in
> > OpenAPI for the type of APIs where it makes sense, such as atomically
> > switching an alias.
> >
> > Sendt fra min iPad
> >
> > 29. okt. 2021 kl. 18:14 skrev Houston Putman :
> >
> >
with autoscaling frameworks of
>> the ancient past, medieval past or the future.
>>
>> On Wed, Nov 3, 2021 at 5:29 AM Timothy Potter wrote:
>>>
>>> As opposed to what? Looking up the configset for the addressed
>>> collection and pulling whatever infor
node when you have easy access to
collection metadata.
Doesn't seem like a hard thing to overcome to me.
On Tue, Nov 2, 2021 at 5:49 PM Noble Paul wrote:
>
>
>
> On Wed, Nov 3, 2021, 10:46 AM Timothy Potter wrote:
>>
>> I'm not missing the point of the quer
n your SIP?
On Tue, Nov 2, 2021 at 5:13 PM Ishan Chattopadhyaya
wrote:
>
> Hi Tim,
> Here are my responses inline.
>
> On Wed, Nov 3, 2021 at 3:22 AM Timothy Potter wrote:
>>
>> I'm just not convinced this feature is even needed and the SIP is not
>>
I'm just not convinced this feature is even needed and the SIP is not
convincing that "There is no proper alternative today."
1) Just b/c Elastic and Vespa have a concept of node roles, doesn't
mean Solr needs this. Also, some of Elastic's roles overlap with
concepts Solr already has in a differen
e “experimental” tag, we could evolve towards the
> OpenAPI spec standards if folks wanted to ;-)
>
> On Oct 29, 2021, at 11:48 AM, Timothy Potter wrote:
>
> Does the v2 API support OpenAPI? I looked over the docs and it seems
> like not, which is a shame. OpenAPI
> (https:/
Does the v2 API support OpenAPI? I looked over the docs and it seems
like not, which is a shame. OpenAPI
(https://swagger.io/specification/) opens up a mature ecosystem of
tooling. The _introspection endpoint seems nice but if automated tools
can't understand it, then our users can't auto-generate
I don't have an opinion on this and don't recall the details from 7+
years ago but I suspect Ram was hoping to warn devs when they were
using ZK inefficiently? I'd have to do some debugging / deeper
investigation to see if these reports are actually still useful for
the current test suite. On the s
Hi Folks,
Having just finished up the 8.10 release, it feels like this is a good
time to start pushing harder for a 9.0 release.
There are so many improvements in the 9 (main) branches and
backporting features to 8x is becoming onerous. I realize Solr needs a
Lucene 9 release before it can procee
can someone who has done this before please publish the 8.10 Docker
image now that the release is done
thanks.
Tim
-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.or
The Solr PMC is pleased to announce the release of Apache Solr 8.10.0.
Solr is the popular, blazing fast, open source NoSQL search platform
from the Apache Lucene project. Its major features include powerful
full-text search, hit highlighting, faceted search, dynamic
clustering, database integrati
The Lucene PMC is pleased to announce the release of Apache Lucene 8.10.0.
Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for
nearly any application that requires full-text search, especially
cross-platform.
This
SUCCESS! [1:04:04.335749]
I also ran through some manual testing with the new s3-repository
contrib using your convenience docker image, and it worked as
expected.
+1
On Fri, Sep 24, 2021 at 4:37 AM Namgyu Kim wrote:
>
> +1 SUCCESS! [1:01:04.224368]
>
> On Thu, Sep 23, 2021 at 12:
Please vote for release candidate 1 for Lucene/Solr 8.10.0
The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
You can run the smoke tester directly with this command:
python3 -u dev-tools/scripts/
x27;s definitely a regression.
>>
>> Uwe
>>
>> Am 20. September 2021 19:13:56 UTC schrieb Timothy Potter
>> :
>>>
>>> Started building the RC1 again today and the smoke tester failed. The
>>> culprit was: org.apache.solr.search.TestFiltering.te
t;> length of
>>>>> >> : > that line shorter than an arbitrary limit.
>>>>> >> : >
>>>>> >> : > Dawid
>>>>> >> : >
>>>>> >> : >
>>>>> >> : > On Wed, Sep 15,
; We have discovered a bug and fixed a bug in Lucene sort optimization
>>> (LUCENE-10106) and would like to merge it to Lucene 8.10 if it is not too
>>> late.
>>> I apologize for the inconvenience, the bug was discovered just yesterday.
>>>
>>>> O
: 8
X-Compile-Target-JDK: 8
Multi-Release: true
On Tue, Sep 14, 2021 at 1:21 PM Ishan Chattopadhyaya
wrote:
>
> All the best, this is the worst step.
>
> On Tue, 14 Sep, 2021, 10:47 pm Timothy Potter, wrote:
>>
>> Building RC1 now ... stay tuned.
>>
>>
Building RC1 now ... stay tuned.
On Thu, Sep 9, 2021 at 2:30 PM Timothy Potter wrote:
>
> Thanks for the update Mike!
>
> I'm backporting SOLR-15620 right now and am cooking up a quick PR for
> SOLR-15621, which looks like an easy win for the issue Cassandra
> reported
working on SOLR-1, the code and benchmarking
> both look pretty good, but I've got a few last unit tests that I need
> to chase down. Hopefully taken care of by today or tomorrow, I'll be
> sure to keep you updated though.
>
>
> On Thu, Sep 9, 2021 at 11:39 AM
+1 (binding) for the Solr Operator v0.4.0 RC1
I ran the smoke tester + tested locally in Docker Desktop + deployed in EKS.
Looks great, thanks Houston!
On Wed, Sep 8, 2021 at 1:00 PM Timothy Potter wrote:
>
> If anyone is interested in testing the Solr operator against the
> recently
I found https://issues.apache.org/jira/browse/SOLR-15620 while testing
the schema designer. I haven't built the RC yet, so going to see if I
can get this in today.
On Tue, Sep 7, 2021 at 12:36 PM Timothy Potter wrote:
>
> NOTICE:
>
> Branch branch_8_10 has been cut and version
If anyone is interested in testing the Solr operator against the
recently cut Solr 8.10 branch, I just pushed a Docker image (built
locally) to: thelabdude/apache-solr-dev:8.10.0-SNAPSHOT
SolrCloud CR YAML:
solrImage:
repository: thelabdude/apache-solr-dev
tag: 8.10.0-SNAPSHOT
Cheers,
yet another branchp
>>> pop when there are last-minute fixes.
>>>
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>>
>>> On Tue, Sep 7, 2021 at 11:53 AM
NOTICE:
Branch branch_8_10 has been cut and versions updated to 8.11 on stable 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
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Sep 7, 2021 at 10:26 AM Timothy Potter wrote:
>>
>> Thanks for the heads up on LUCENE-10088 Mike. I'd still like to cut
>> the release branch t
file
> handle leak.
>
> If so, this might be a blocker for 8.10.0 release.
>
> I'll try to make progress today on getting to the root cause.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Thu, Sep 2, 2021 at 1:43 PM Timothy Potter wrote
lease in a long
>> time?
>>
>> Mike
>>
>> On Thu, Aug 26, 2021 at 4:09 AM Adrien Grand wrote:
>>>
>>> +1 to a 8.10 release and cutting a branch next week
>>>
>>> On Tue, Aug 24, 2021 at 8:02 PM Timothy Potter wrote:
>&
;>> > - SOLR-15596 - This is important but I don't think there's any work for
>>> > it yet.
>>> >
>>> > - Houston
>>> >
>>> > On Sat, Aug 28, 2021 at 12:18 PM Michael McCandless
>>> > wrote:
>>>
obviously depends on our decision around these open blockers.
Cheers,
Timothy Potter
PS ~ I volunteer to be the Release Manager ;-)
-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h
ging code!
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Timothy Potter
> > Sent: Thursday, August 12, 2021 10:31 PM
> > To: dev@so
Not just our CI ... same failure here:
https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/2184/
On Thu, Aug 12, 2021 at 2:03 PM Timothy Potter wrote:
>
> I'm seeing the following failure on branch_8x which looks like new
> code added to the test in commit:
> https://github.
I'm seeing the following failure on branch_8x which looks like new
code added to the test in commit:
https://github.com/apache/lucene-solr/commit/d99980516bd3470e9e120428914d1270d5ddf91b
It passes locally in my IDE but fails in an internal Jenkins server
running JDK 11 & 15:
java.lang.AssertionEr
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 thes
To be clear, I meant did the Solr pod get killed while it was creating
the _default configset? (Not when creating your test collection, the
problem already existed once you got to that point, obviously)
On Mon, Jun 21, 2021 at 4:01 PM Timothy Potter wrote:
>
> I've not seen this hap
I've not seen this happen ... did your Solr pod get killed during this
operation? I'm not sure if this copy operation could be done as a
multi given the jute buffer limitations (iirc, the total size of all
setData for a multi must be under the jute buffer size) ... so it's
possible to end up with a
Agreed. I think they should be removed when the official release image
comes out ;-)
On Mon, May 24, 2021 at 9:45 AM Jan Høydahl wrote:
>
> The RCs are not releases, they are candidates, so we don't have any
> obligations to anyone regarding them. Removing them should be part of release
> proce
I think I was just the reviewer / committer on that SOLR-6370, before
Ram was made committer, so I don't have a ton of background on the
actual work done. The JIRA gives some details on the intent.
Overall, I agree this is probably not actively used for much other
than reporting at the end of test
Logo: L-3, L-2
Icon: I-1
(binding)
On Wed, Apr 28, 2021 at 1:02 PM Jason Gerlowski wrote:
>
> (binding)
> Logo vote: L4, L-1
> Icon vote: I-4
>
> On Tue, Apr 27, 2021 at 8:34 PM Gus Heck wrote:
> >
> > (binding)
> > L-2 L-1 L-3
> > I-3 I-2 I-1
> >
> > On Tue, Apr 27, 2021 at 5:00 PM Houston
ese simple transformations are happening. I'm all
for making option #3 (mutations) an opt-in vs. opt-out as it is now
esp. now that we'll soon have a Schema Designer in the UI.
On Wed, Apr 28, 2021 at 4:18 PM Timothy Potter wrote:
>
> I agree with Alex here. We can't overload beg
I agree with Alex here. We can't overload beginners with a bunch of
jargon and complexity just because experts understand how to use curl
effectively. I also don't think we should remove a feature b/c one
instance of misuse is found in the wild, sounds like Gus' client was
being lazy. Better docs a
+1 (binding)
Smoke tester passed + deployed to GKE with TLS / Basic Auth / ZK ACLs
Also verified running w/o installing the ZK CRD, using the Bitnami ZK
Helm chart instead of the ZK operator, works great!
Excellent work Houston!
On Tue, Apr 27, 2021 at 9:52 AM Houston Putman wrote:
>
> I teste
+1 (binding)
Ran the smoke tester and deployed a 3-node to GKE with TLS + basic
auth + anti-affinity + auto-scaling policy + prom / grafana metrics +
zone aware query routing ~ the works!
Thank you for the amazing work on this release Houston.
On Wed, Apr 21, 2021 at 3:55 PM Houston Putman wrot
Looks like your latest commit David -->
https://github.com/apache/solr/commit/7877c914b9035422e380251be42948b924fe72fa
> Task :solr:core:ecjLintTest
164--
1651. ERROR in
/home/runner/work/solr/solr/solr/core/src/test/org/apache/solr/handler/admin/LukeRequestHandlerTest.java
(at line 22)
1
This looks like something funky with my gnupg setup locally, but I got this:
helm install --debug --verify solr-operator
solr-operator-rc/solr-operator --set image.tag=v0.3.0-rc1
install.go:172: [debug] Original chart version: ""
Error: failed to load keyring: open /Users/tjp/.gnupg/pubring.gpg: n
Looks good!
+1 (binding)
Ran the smoke tester + verified the ACLs on /security.json. Also ran
through a series of indexing / query load tests with the Solr
operator.
Cheers,
Tim
On Wed, Apr 7, 2021 at 9:22 AM Uwe Schindler wrote:
>
> Hi,
>
>
>
> sorry I haven’t seen your message before (it was
69 matches
Mail list logo
