I was hoping someone more familiar with SKG's test/code that I found a failure for might chime in. It looks like it's a case where enum facets are not producing all results produced for default faceting, which seems possibly bad, but I am not familiar with this code at all. This probably is localized to Semantic Knowledge Graphs (which after some digging is what SKG stands for... be nice if that were in the comments for the class)... so the question is do we want to release with a known break in that feature I guess. I'm inclined to say no, but I am certainly not going to be able to dig into SKG's to fix this in a timely fashion. So I guess the question is is SKG important enough to someone out there to fix it soon?
Also looks like the code iterates across possible parameter values and fails on the first one to go wrong so there may be other failure cases for STREAM or SMART hiding behind this... -Gus On Mon, May 2, 2022 at 6:55 AM Jan Høydahl <jan....@cominvent.com> wrote: > Hi, > > If I close the vote now, it will technically pass with four +1s, one -1 > and one -0. A bit too fragile result IMO. > > I would too like to understand the severity of the configsets bug, and > whether it is serious enough to stop the release. > As I understand the issue, it ONLY affects those creating a new configset > based on another one in ZK. > I.e. there are many workarounds for this bug > - Use an authenticated user when creating configset (and not an > "untrusted" one) > - Upload a new configset rather than basing it on an existing? > - Upload configset directly to Zookeeper > > Please verify or shoot down my assumption. If my assumption is correct, > I'll keep my +1 vote, and wait for a few more +1s before closing the vote. > If the issue is indeed more serious and there are more -1's, I'll happily > respin after the fix. > > Jan > > > 29. apr. 2022 kl. 21:03 skrev Gus Heck <gus.h...@gmail.com>: > > -0 for now, pending discussion of severity... I have hit a reproducing > failure: > > ./gradlew :solr:core:test --tests > "org.apache.solr.search.facet.TestCloudJSONFacetSKGEquiv.testRandom" > -Ptests.jvms=5 -Ptests.jvmargs=-XX:TieredStopAtLevel=1 > -Ptests.seed=C730F33909C71234 -Ptests.badapples=false > -Ptests.file.encoding=UTF-8 > > On Fri, Apr 29, 2022 at 1:28 PM Kevin Risden <kris...@apache.org> wrote: > >> Smoketester passed on the second try for me: SUCCESS! [1:29:24.214674] >> >> The first failure was "gradlew :solr:core:test --tests >> "org.apache.solr.cloud.HttpPartitionOnCommitTest.test" -Ptests.jvms=4 >> -Ptests.jvmargs=-XX:TieredStopAtLevel=1 -Ptests.seed=66730F3AEF630DB6 >> -Ptests.badapples=false -Ptests.file.encoding=US-ASCII". I haven't >> reproduced it yet. >> >> However it looks like the configsets API is broken with one of the >> simpler examples. Eric Pugh found this the other day and asked me to >> check on 9.0 RC4: https://issues.apache.org/jira/browse/SOLR-16164 >> >> I'm still poking around the release today. >> >> Based on the configset api error - I'm -1 for releasing. >> >> Kevin Risden >> >> >> On Fri, Apr 29, 2022 at 11:26 AM Mike Drob <md...@apache.org> wrote: >> >>> +1 (binding) >>> >>> >>> Smoketester succeeded with Java 11 and Java 17 -- SUCCESS! >>> [2:04:03.678208] >>> >>> Unlike for some others, this succeeded on my first try. I guess I'm just >>> lucky :) >>> >>> >>> Tested building an application that uses EmbeddedSolrServer and depends >>> on our maven artifacts - validated SOLR-16157, SOLR-16117 >>> >>> Tested a mixed state cluster with 8.11.1 and 9.0.0 nodes (no security). >>> Queries worked as expected. >>> Tested a rolling upgrade from 8.11.1 to 9.0.0 with basic authentication >>> enabled. Queries failed (as expected) at first, but then succeeded when >>> setting solr.pki.sendVersion=v1 and solr.pki.acceptVersions=v1,v2on the >>> Solr 9 node, as described in our ref guide and upgrade notes. >>> >>> Manually checked for license headers in source release, missing headers >>> on the following: >>> * SYSTEM_REQUIREMENTS.md >>> * solr/core/src/resources/SystemCollection*.xml >>> * lots and lots of stuff under solr-ref-guide, unclear which pieces of >>> this are our code and which are copied from external sources. >>> * modules/*/README.md >>> >>> Will file a follow up JIRA for the license issues. >>> >>> On Wed, Apr 27, 2022 at 8:15 AM Jan Høydahl <jan....@cominvent.com> >>> wrote: >>> >>>> Please vote for release candidate 4 for Solr 9.0.0 >>>> >>>> The artifacts can be downloaded from: >>>> >>>> https://dist.apache.org/repos/dist/dev/solr/solr-9.0.0-RC4-rev-d6e36d590896755ca962c6d2ddedf78ca4f463cc >>>> >>>> You can run the smoke tester directly with this command: >>>> >>>> python3 -u dev-tools/scripts/smokeTestRelease.py \ >>>> >>>> https://dist.apache.org/repos/dist/dev/solr/solr-9.0.0-RC4-rev-d6e36d590896755ca962c6d2ddedf78ca4f463cc >>>> >>>> You are encouraged to do an extra thorough test and manual inspection >>>> beyond >>>> running the smoketester, since this is a major release. >>>> >>>> You can build a release-candidate of the official docker image using >>>> the following command: >>>> >>>> DIST_BASE=https://dist.apache.org/repos/dist/dev/solr && \ >>>> RC_FOLDER=solr-9.0.0-RC4-rev-d6e36d590896755ca962c6d2ddedf78ca4f463cc >>>> && \ >>>> docker build $DIST_BASE/$RC_FOLDER/solr/docker/Dockerfile.official \ >>>> --build-arg >>>> SOLR_DOWNLOAD_URL=$DIST_BASE/$RC_FOLDER/solr/solr-9.0.0.tgz \ >>>> -t solr-rc:9.0.0-4 >>>> >>>> The vote will be open for at least 72 hours i.e. until 2022-04-30 13:00 >>>> UTC. >>>> >>>> [ ] +1 approve >>>> [ ] +0 no opinion >>>> [ ] -1 disapprove (and reason why) >>>> >>>> Here is my +1 >>>> >>>> SUCCESS! [0:56:56.134141] >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>> >>>> > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
