Anyone familiar with HDFS and Solr and snapshotcli.sh?
Hey all, so https://github.com/apache/solr/pull/2381 moves the various commands for doing a snapshot from the /solr/server/cloud-scripts/snapshotcli.sh script into the bin/solr overall structure! I had no idea that we had CLI tooling for managing snapshots! The one slightly icky/weird thing is that there are some steps that if you are running HDFS, and you want to use the "hadoop distcp tool" then those don't go through the Java tooling, they are specific to the HDFS module. In the PR, I've added to the modules/hdfs/bin the script for workign with the hadoop distcp tool. However, since I'm not familiar with how that all works, and we don't have any BATS tests, well, I'm a bit nervous about the changes. So, I'd love to ask for some help testing this. Anyone using the HDFS and Solr stuff in production willing to work with me to test this out? What I'd really like is to get the BATS testing of the hadoop stuff developed so we can feel more confident making changes. Eric
subscribe
Re: JSON Parsing, Jackson / Noggit
The lenient parsing thing is cool till you try to take the same json structure and use it in something else and it blows up. I’d love to see a comparison of the performance differences, and assuming no diff or minimal, then move to Jackson! > On Aug 5, 2024, at 1:03 PM, Gus Heck wrote: > > IIUC there were supposed to be memory advantages to noggit. I have not seen > this quantified, and the relevance of those advantages over current jackson > (vs libs available in the early 2000's) seems like a valid thing to > investigate. > > Unfortunately, we have areas where we support json with duplicate keys, > which while technically legal JSON is unexpected by most default parser > usages and an anathema for mapping the json into an object in an object > oriented language. > > We also support extra trailing commas in lists which violates the spec IIUC. > > It's hard to justify a change until > > 1. there is a demonstrated performance advantage, or > 2. those API's have been redesigned, or > 3. Someone takes the time to figure out how to make Jackson play nice > with the oddities we support, and writes reusable utilities to ensure > consistency so that it's transparent to users > > > > On Mon, Aug 5, 2024 at 11:53 AM David Smiley wrote: > >> We have a couple JSON Parsing libraries -- "Noggit" (internal to Solr) >> and "Jackson". Noggit is more lenient in parsing. I suppose Solr >> should use Noggit for parsing JSON coming into it, but AFAIK Solr only >> returns/emits valid JSON; yes? For parsing JSON that we assume is >> compliant (e.g. from Solr), should we prefer Jackson or Noggit? Are >> there performance advantages? >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> >> > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: [DISCUSS] Solr 9.7 release
I had earlier asked to wait to get both https://github.com/apache/solr/pull/2593 and https://github.com/apache/solr/pull/2577 into 9.7. 2577 is in, and Jenkins for main and branch_9x seem to have passed (the failures are on the prometheus tests)…. 2577 fixes a lot of documentation and user messages and I think is important for 9.7. 2593 needs more work, and is all “behind the scenes” changes, so if it ends up in 9.8 that is okay. Eric > On Aug 3, 2024, at 12:59 AM, David Smiley wrote: > > The release branch has not yet been cut. Anshum, based on your > comments, I think you should cut it. I would like to merge things to > branch_9x without it going to 9.7 as I would like more bake time on > some things. > > On Fri, Aug 2, 2024 at 3:09 PM Gus Heck wrote: >> >> For https://issues.apache.org/jira/browse/SOLR-17298 >> >> I think the key thing that remains is to verify if the exclusion of >> graph/join/rerank queries really is correct. The tests didn't fail out of >> the box when I removed that restriction, but I want to add some tests that >> explicitly turn it on to be sure. >> >> -Gus >> >> On Fri, Aug 2, 2024 at 2:50 PM Anshum Gupta wrote: >> >>> Do we have an estimate on when the open issues will get wrapped up? I >>> certainly would recommend that we don't rush with releasing code and >>> instead let it bake. If it's almost done, I can create the branch early >>> next week and wait a couple of days before moving forward with the release. >>> >>> There's no rush, but I wouldn't want to be blocked indefinitely. >>> >>> On Thu, Aug 1, 2024 at 1:14 PM David Smiley wrote: >>> >>>> For the Prometheus test failures, I re-opened the issue. Consider >>>> that one just test noise; we should ignore it if it doesn't get fixed >>>> soon. >>>> https://issues.apache.org/jira/browse/SOLR-17368 >>>> >>>> On Thu, Aug 1, 2024 at 8:34 AM Gus Heck wrote: >>>>> >>>>> Also looking at >>>> http://fucit.org/solr-jenkins-reports/failure-report.html >>>>> we have a couple tests with high fail rates. This one seems to be >>>>> reproducible (reliably with seed, but also not hard to generate >>> without) >>>>> >>>>> org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest > >>>> testNoAuth >>>>> FAILED >>>>>java.lang.AssertionError: Give up waiting for no results: >>>>> >>>> >>> q=should_expire_s:yup=0&_trace=init_batch_check&_stateVer_=expiring:13 >>>>> expected:<0> but was:<55> >>>>>at >>>>> >>> __randomizedtesting.SeedInfo.seed([11EF0AA307058EA1:CD5AB0CEBDD35C89]:0) >>>>> >>>>> 2> 563294 ERROR (qtp1873537458-54511-null-134677) [n:127.0.0.1:34489 >>>> _solr >>>>> c:expiring_secure s:shard2 r:core_node7 >>>> x:expiring_secure_shard2_replica_n3 >>>>> t:null-134677] o.a.s.h.RequestHandlerBase Client exception >>>>> 2> => org.apache.solr.common.SolrException: can not use >>>>> FieldCache on a field w/o docValues unless it is indexed >>>> uninvertible=true >>>>> and the type supports Uninversion: _version_ >>>>> 2> at >>>>> >>>> >>> org.apache.solr.schema.SchemaField.checkFieldCacheSource(SchemaField.java:295) >>>>> >>>>> On Thu, Aug 1, 2024 at 7:22 AM Christine Poerschke (BLOOMBERG/ LONDON) >>> < >>>>> cpoersc...@bloomberg.net> wrote: >>>>> >>>>>> If there is time I'd like to nominate >>>>>> https://issues.apache.org/jira/browse/SOLR-17386 and >>>>>> https://github.com/apache/solr/pull/2607 to be in the 9.7 release. >>>>>> >>>>>> -Christine >>>>>> >>>>>> From: dev@solr.apache.org At: 07/29/24 15:50:24 UTC+1:00To: >>>>>> dev@solr.apache.org >>>>>> Subject: Re: [DISCUSS] Solr 9.7 release >>>>>> >>>>>> https://issues.apache.org/jira/browse/SOLR-17298 is more or less >>>> ready, >>>>>> but >>>>>> would like it to at least have a few days sitting in main before I >>>> backport >>>>>> it. Without it the multi-threaded search needs to be documented as >>> not >>>>>> working with cpuTimeAl
Re: A thought for our release process...
Yeah..I guess if I want the “over all holistic look”, I probably need to just volunteer to do it! And honestly, maybe we make too big of a deal of CHANGES.txt? > On Jul 26, 2024, at 6:58 AM, Gus Heck wrote: > > There is currently such a step, but it's focused on looking for duplicate > entries. Editorial review at release time is difficult because Solr is so > big, and probably almost nobody stays on top of all the changes. Review at > PR/Checkin would seem to me to be the best route. > > On Wed, Jul 24, 2024 at 2:46 PM Eric Pugh <mailto:ep...@opensourceconnections.com>> > wrote: > >> Fair on the “make work” side of things. I know I skim through it at >> various times, but we also have our Migration guide in the Ref Guide too…. >> >> I do look forward to a future with a simpler less confusing CHANGES.txt! >> >>> On Jul 24, 2024, at 2:21 PM, David Smiley wrote: >>> >>> I like the idea yet I also wonder if most folks simply won't care to >>> provide any input anyway, and then it becomes just yet another release >>> task. Also, I wouldn't want to recommend any process that would need >>> to be rethought if we streamline CHANGES.txt management (e.g. we spoke >>> of using separate files and a script that generates a combined one). >>> But we could piggy-back off of such... like that would end up >>> generating a CHANGES.txt section of the release, and thus it could >>> easily be posted as a PR for follow-up editing. >>> >>> On Wed, Jul 24, 2024 at 12:44 PM Eric Pugh >>> wrote: >>>> >>>> I was thinking that as part of our release process we should have a >> “review CHANGES.txt” step? I don’t know if that is already in there, but >> it might be a good step for us as a community to have a single point in >> time to review that to make sure it’s clear and accurate…. >>>> >>>> We have lots of folks contributing to it, each with their own style and >> their own opinion of what change is what type of change, and so maybe >> having a step in the release process to say “Hey, now is the time to review >> these to make it look the best it can” might help? >>>> >>>> Eric >>>> >>>> ___ >>>> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw >>> >>>> 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 >>> >> >> ___ >> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >> 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. >> >> > > -- > http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: [DISCUSS] Solr 9.7 release
Really hoping to get https://github.com/apache/solr/pull/2593 and https://github.com/apache/solr/pull/2577 in for 9.7 as well. I’ve asked on the user mailing list for help testing the changes out on Windows, so hopefully we get some confirmation the work I’ve done is bug free and it won’t hold up the 9.7 release process. > On Jul 25, 2024, at 3:09 PM, Gus Heck wrote: > > I hadn't realized it wasn't marked for 9.7 but > https://issues.apache.org/jira/browse/SOLR-17298 was always intended as a > blocker as well. > > On Thu, Jul 25, 2024 at 12:31 PM Anshum Gupta > wrote: > >> Sure, I'll wait until the 30th. Thanks for letting me know. >> >> On Wed, Jul 24, 2024 at 9:39 PM Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com> wrote: >> >>> Hi Anshum, >>> I'm still working on unblocking SOLR-13350. Can we please push the date >>> back by a week, say 30 July? >>> >>> Thanks and regards, >>> Ishan >>> >>> On Wed, 24 Jul, 2024, 10:52 pm Anshum Gupta, >>> wrote: >>> >>>> As there are still a few dependency upgrade PRs open, I'll give it a >> few >>>> days and try and help review + merge those in before starting the >> process >>>> later this week. >>>> >>>> On Wed, Jul 17, 2024 at 10:04 AM Eric Pugh < >>>> ep...@opensourceconnections.com> >>>> wrote: >>>> >>>>> I would like to see the back port of solr cli changes make it… >>>>> https://github.com/apache/solr/pull/2540 >>>>> >>>>> Thanks to some great work from Jan I suspect it can be committed this >>>> week. >>>>> >>>>> >>>>> >>>>> On Wed, Jul 17, 2024 at 6:55 PM David Smiley >>> wrote: >>>>> >>>>>> There is at least one blocker, a notable one: >>>>>> https://issues.apache.org/jira/browse/SOLR-13350 (search segments >> in >>>>>> parallel) >>>>>> >>>>>> On Tue, Jul 16, 2024 at 4:12 PM Anshum Gupta >>>> wrote: >>>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> The Change log for Solr 9.7 looks pretty good already with the >>> Lucene >>>>>>> upgrade and a bunch of other fixes, improvements, and features. >>>>>>> >>>>>>> I'd like to start the release process next *Tuesday, July 23 >>> *unless >>>>>> there >>>>>>> are objections or reasons to wait. >>>>>>> >>>>>>> -Anshum >>>>>> >>>>>> >> - >>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Anshum Gupta >>>> >>> >> >> >> -- >> Anshum Gupta >> > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: A thought for our release process...
Fair on the “make work” side of things. I know I skim through it at various times, but we also have our Migration guide in the Ref Guide too…. I do look forward to a future with a simpler less confusing CHANGES.txt! > On Jul 24, 2024, at 2:21 PM, David Smiley wrote: > > I like the idea yet I also wonder if most folks simply won't care to > provide any input anyway, and then it becomes just yet another release > task. Also, I wouldn't want to recommend any process that would need > to be rethought if we streamline CHANGES.txt management (e.g. we spoke > of using separate files and a script that generates a combined one). > But we could piggy-back off of such... like that would end up > generating a CHANGES.txt section of the release, and thus it could > easily be posted as a PR for follow-up editing. > > On Wed, Jul 24, 2024 at 12:44 PM Eric Pugh > wrote: >> >> I was thinking that as part of our release process we should have a “review >> CHANGES.txt” step? I don’t know if that is already in there, but it might >> be a good step for us as a community to have a single point in time to >> review that to make sure it’s clear and accurate…. >> >> We have lots of folks contributing to it, each with their own style and >> their own opinion of what change is what type of change, and so maybe having >> a step in the release process to say “Hey, now is the time to review these >> to make it look the best it can” might help? >> >> Eric >> >> ___ >> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com <http://www.opensourceconnections.com/> >> | My Free/Busy <http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed >> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> 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 > ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
A thought for our release process...
I was thinking that as part of our release process we should have a “review CHANGES.txt” step? I don’t know if that is already in there, but it might be a good step for us as a community to have a single point in time to review that to make sure it’s clear and accurate…. We have lots of folks contributing to it, each with their own style and their own opinion of what change is what type of change, and so maybe having a step in the release process to say “Hey, now is the time to review these to make it look the best it can” might help? Eric ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Some PR's to get some eyes on!
Hey all, so slowly closing in on wrapping up the SolrCLI epic…. I plan on giving an update at Thursday’s community meetup. In the mean time, there are some PR’s id’ love some more eyes on: https://github.com/apache/solr/pull/2580 - SOLR-15831: Refactor bin/solr and bin/solr.cmd to delegate args parsing and usage help to SolrCLI This one is based on some great work that Tim Potter did back int he day. https://github.com/apache/solr/pull/2577 - SOLR-16824: Replace deprecated single-dash arguments Contributed by community member Christos, it moved along updating lots of files. https://github.com/apache/solr/pull/2479 - SOLR-14673: Add bin/solr stream CLI This is based on an old patch file from Joel Bernstein, but updated for the current world. Pretty chuffed by that I can cat a CSV file directly into Solr! cat example/exampledocs/books.csv | bin/solr stream -e local 'update(gettingstarted,parseCSV(stdin()))' Would love some feedback on these. Eric ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: [DISCUSS] Community Virtual Meetup, July 2024
Looking forward to it! > On Jul 18, 2024, at 6:54 PM, David Smiley wrote: > > Thanks; yes that works for me. > > On Thu, Jul 18, 2024 at 9:05 AM Jason Gerlowski wrote: >> >> Alright, >> >> I'm happy to organize this month. I'll create the meeting notes pages >> and links shortly. >> >> As for a time/date, how would 9am PT (noon ET) on Thursday the 25th >> work for everyone? >> >> Best, >> >> Jason >> >> On Mon, Jul 15, 2024 at 8:31 AM Jason Gerlowski >> wrote: >>> >>> Hey all, >>> >>> It's time once again to start thinking ahead to this month's virtual meetup! >>> >>> As always, two questions: >>> >>> 1. Does anyone have an interest in organizing? Duties are light but >>> it's an important job. I'm happy to organize by default if there >>> aren't any volunteers in the next day or two. (Addtl details: >>> https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes) >>> >>> 2. Does anyone have preferences on the date or time-of-day? Maybe we >>> could shoot for time-slot sometime in the middle of next week? >>> >>> Best, >>> >>> Jason >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: [DISCUSS] Solr 9.7 release
I would like to see the back port of solr cli changes make it… https://github.com/apache/solr/pull/2540 Thanks to some great work from Jan I suspect it can be committed this week. On Wed, Jul 17, 2024 at 6:55 PM David Smiley wrote: > There is at least one blocker, a notable one: > https://issues.apache.org/jira/browse/SOLR-13350 (search segments in > parallel) > > On Tue, Jul 16, 2024 at 4:12 PM Anshum Gupta wrote: > > > > Hi everyone, > > > > The Change log for Solr 9.7 looks pretty good already with the Lucene > > upgrade and a bunch of other fixes, improvements, and features. > > > > I'd like to start the release process next *Tuesday, July 23 *unless > there > > are objections or reasons to wait. > > > > -Anshum > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
Re: SIP-7 New Admin UI
> Overall, this sounds like a reasonable approach to me. >>>>>>>>>> >>>>>>>>>> I think a big concern with putting code in the main repo is >>>> that >>>>>> it's >>>>>>>>>> pretty far from the (current) PMC's/community's wheelhouse to >>>>>>>>>> maintain. I definitely share that concern. But IMO we're >>>> already >>>>>>>>>> sortof at a "worst case" in that regard with our existing >>>> Admin UI >>>>>>>>>> code. Doing the "refresh" in the main repo gives us a forcing >>>>>>>>>> function (i.e. the review process itself) to ensure that at >>>> least a >>>>>>>>>> few community members will understand the code to at least some >>>>>>>>>> extent. That'll be a huge improvement over where we are today. >>>>>>>>>> >>>>>>>>>> Anyway, I'm a cautious '+1' based on these details at least. >>>> To >>>>>>> quote >>>>>>>>>> a message from Jan in Slack: "I'd rather see some imperfect >>>>>> movement >>>>>>>>>> than a perfect plan never realized." >>>>>>>>>> >>>>>>>>>> (Here's hoping my reply will bump this to the top of folks' >>>>>> Inboxes, >>>>>>>>>> and get you some more feedback.) >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> >>>>>>>>>> Jason >>>>>>>>>> >>>>>>>>>> On Mon, Jul 1, 2024 at 12:25 PM Christos Malliaridis >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello everyone, >>>>>>>>>>> >>>>>>>>>>> In regards to SIP-7 >>>>>>>>>>> < >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >> https://cwiki.apache.org/confluence/display/SOLR/SIP-7+Updated+Solr+Admin+UI >>>>>>>>>>> >>>>>>>>>>> and SIP-10 >>>>>>>>>>> < >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >> https://cwiki.apache.org/confluence/display/SOLR/SIP-10+Improve+Getting+Started+experience >>>>>>>>>>> >>>>>>>>>>> I would like to add my perspective and address the current >>>>>> concerns >>>>>>>>> about >>>>>>>>>>> implementing a new UI, so that we can take some actions and >>>>>>> improve the >>>>>>>>>>> overall quality and experience of Solr Admin UI. >>>>>>>>>>> >>>>>>>>>>> There are many discussions and opinions about the UI and how >>>> to >>>>>>> resolve >>>>>>>>>> the >>>>>>>>>>> current issues, but they all led to the topic becoming >>>> stale. In >>>>>> my >>>>>>>>>>> opinion, developing and introducing a new UI into the main >>>>>>> repository >>>>>>>>>> piece >>>>>>>>>>> by piece without replacing the current UI until >>>> feature-complete >>>>>>> could >>>>>>>>>>> >>>>>>>>>>> - address all the issues currently reported (and not), >>>>>>>>>>> - add new features, >>>>>>>>>>> - replace the EOL framework and >>>>>>>>>>> - improve the overall user experience. >>>>>>>>>>> >>>>>>>>>>> And the maintenance, which is one of the most important >>>> parts, >>>>>>> could be >>>>>>>>>>> addressed with the right choice of framework. >>>>>>>>>>> >>>>>>>>>>> I created a detailed writeup >>>>>>>>>>> < >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >> https://docs.google.com/document/d/14F1QARdkIrmKXQ4zuWUuOXduH4v_XwZ_Zrd0d2jE468/edit?usp=sharing >>>>>>>>>>> >>>>>>>>>>> for those who are interested, where I also write about the >>>>>>> alternative >>>>>>>>>>> approaches proposed in the past and listing the pros and >>>> cons of >>>>>>> each >>>>>>>>> one >>>>>>>>>>> individually. >>>>>>>>>>> >>>>>>>>>>> I also started to improve this part by simply designing a >>>> new UI >>>>>>>>>>> < >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >> https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept >>>>>>>>>>> >>>>>>>>>>> and addressing multiple issues at once. I have already >>>> received >>>>>>> some >>>>>>>>>> community >>>>>>>>>>> feedback >>>>>>>>>>> < >>>>>>> https://apachesolr.slack.com/archives/C01GVPZSSK0/p1718289047297999 >>>>> , >>>>>>>>>> but >>>>>>>>>>> it is far from production-ready and needs more input. I think >>>>>> this >>>>>>>>> could >>>>>>>>>> be >>>>>>>>>>> further refined and moved to development if there is >>>> consensus on >>>>>>> that >>>>>>>>> as >>>>>>>>>>> the initial approach. >>>>>>>>>>> >>>>>>>>>>> What's your opinion about this approach and do you have any >>>>>>> concerns >>>>>>>>> that >>>>>>>>>>> have not been addressed? >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Christos >>>>>>>>>> >>>>>>>>>> >>>>>> - >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> http://www.needhamsoftware.com (work) >>>>>>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >>>>>>> >>>>>>> - >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> http://www.needhamsoftware.com (work) >>>>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >>>>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>> >>>> >> ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: SIP-7 New Admin UI
ve alongside the existing one (for a time) >>>>>>>> 2. The code for the new UI would live in the main repository. >>>>>>>> 3. Development would be piece-meal (i.e. not one big code-dump) >>>>>>>> >>>>>>>> Overall, this sounds like a reasonable approach to me. >>>>>>>> >>>>>>>> I think a big concern with putting code in the main repo is >> that >>>> it's >>>>>>>> pretty far from the (current) PMC's/community's wheelhouse to >>>>>>>> maintain. I definitely share that concern. But IMO we're >> already >>>>>>>> sortof at a "worst case" in that regard with our existing >> Admin UI >>>>>>>> code. Doing the "refresh" in the main repo gives us a forcing >>>>>>>> function (i.e. the review process itself) to ensure that at >> least a >>>>>>>> few community members will understand the code to at least some >>>>>>>> extent. That'll be a huge improvement over where we are today. >>>>>>>> >>>>>>>> Anyway, I'm a cautious '+1' based on these details at least. >> To >>>>> quote >>>>>>>> a message from Jan in Slack: "I'd rather see some imperfect >>>> movement >>>>>>>> than a perfect plan never realized." >>>>>>>> >>>>>>>> (Here's hoping my reply will bump this to the top of folks' >>>> Inboxes, >>>>>>>> and get you some more feedback.) >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Jason >>>>>>>> >>>>>>>> On Mon, Jul 1, 2024 at 12:25 PM Christos Malliaridis >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello everyone, >>>>>>>>> >>>>>>>>> In regards to SIP-7 >>>>>>>>> < >>>>>>>> >>>>>>> >>>>> >>>> >> https://cwiki.apache.org/confluence/display/SOLR/SIP-7+Updated+Solr+Admin+UI >>>>>>>>> >>>>>>>>> and SIP-10 >>>>>>>>> < >>>>>>>> >>>>>>> >>>>> >>>> >> https://cwiki.apache.org/confluence/display/SOLR/SIP-10+Improve+Getting+Started+experience >>>>>>>>> >>>>>>>>> I would like to add my perspective and address the current >>>> concerns >>>>>>> about >>>>>>>>> implementing a new UI, so that we can take some actions and >>>>> improve the >>>>>>>>> overall quality and experience of Solr Admin UI. >>>>>>>>> >>>>>>>>> There are many discussions and opinions about the UI and how >> to >>>>> resolve >>>>>>>> the >>>>>>>>> current issues, but they all led to the topic becoming >> stale. In >>>> my >>>>>>>>> opinion, developing and introducing a new UI into the main >>>>> repository >>>>>>>> piece >>>>>>>>> by piece without replacing the current UI until >> feature-complete >>>>> could >>>>>>>>> >>>>>>>>> - address all the issues currently reported (and not), >>>>>>>>> - add new features, >>>>>>>>> - replace the EOL framework and >>>>>>>>> - improve the overall user experience. >>>>>>>>> >>>>>>>>> And the maintenance, which is one of the most important >> parts, >>>>> could be >>>>>>>>> addressed with the right choice of framework. >>>>>>>>> >>>>>>>>> I created a detailed writeup >>>>>>>>> < >>>>>>>> >>>>>>> >>>>> >>>> >> https://docs.google.com/document/d/14F1QARdkIrmKXQ4zuWUuOXduH4v_XwZ_Zrd0d2jE468/edit?usp=sharing >>>>>>>>> >>>>>>>>> for those who are interested, where I also write about the >>>>> alternative >>>>>>>>> approaches proposed in the past and listing the pros and >> cons of >>>>> each >>>>>>> one >>>>>>>>> individually. >>>>>>>>> >>>>>>>>> I also started to improve this part by simply designing a >> new UI >>>>>>>>> < >>>>>>>> >>>>>>> >>>>> >>>> >> https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept >>>>>>>>> >>>>>>>>> and addressing multiple issues at once. I have already >> received >>>>> some >>>>>>>> community >>>>>>>>> feedback >>>>>>>>> < >>>>> https://apachesolr.slack.com/archives/C01GVPZSSK0/p1718289047297999 >>> , >>>>>>>> but >>>>>>>>> it is far from production-ready and needs more input. I think >>>> this >>>>>>> could >>>>>>>> be >>>>>>>>> further refined and moved to development if there is >> consensus on >>>>> that >>>>>>> as >>>>>>>>> the initial approach. >>>>>>>>> >>>>>>>>> What's your opinion about this approach and do you have any >>>>> concerns >>>>>>> that >>>>>>>>> have not been addressed? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Christos >>>>>>>> >>>>>>>> >>>> - >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> http://www.needhamsoftware.com (work) >>>>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >>>>> >>>>> - >>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>> >>>>> >>>> >>>> -- >>>> http://www.needhamsoftware.com (work) >>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >>>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> >> ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Looking for final review of SOLR-16842
Hi all…. Quick update that I merged SOLR-16842 into main. I wanted to confirm that our Jenkins builds are still happy, and while our normal Jenkins boxes are busted, I see that we have “Solr-Check-main-s390x”? Looking at it, it appears that recent code merges are fine, that the one test that failed on run https://ci-builds.apache.org/job/Solr/job/Solr-Check-main-s390x/646/ is probably just flaky. So feeling good about that! https://ci-builds.apache.org/job/Solr/job/Solr-Check-main-s390x/ I have started a back port PR to branch_9x, however it’s not going well…. :-(. https://github.com/apache/solr/pull/2540. There are more differences between main and branch_9x for the CLI than I quite realized. Bats tests on main that aren’t on branch_9x, all the changes in how we craft Solr urls, the fact that we never back ported basic auth for SolrCLI tools…. We replaced “CreateCoreTool" and “CreateCollectionTool" tools with “CreateTool” on main... I haven’t committed all my local changes as the tests are failing, but may try that…. I’m running out of time before vacation for three weeks (hello Spain!) and so thinking: 1) Ask for help. If someone else wanted to take a crack at the back port who has more Git-fu than I do, more than welcome. 2) Push up the code to the branch even though tests etc fail. 3) Not worry about back port to branch_9x till I get back last week of July. 4) Pivot on the back port plan and declare SOLR-16842 to be a Solr 10 only feature. Figure out a new plan for removing deprecated options from code. (That is starting to feel the path of least resistance to me). I would very much like to NOT rollback the change so didn’t list that as an option…. Thanks Eric > On Jun 22, 2024, at 10:05 AM, Eric Pugh > wrote: > > Thanks Jason, I’m happy to stall till end of day on Monday to click “merge”! > Thanks. > > >> On Jun 21, 2024, at 12:33 PM, Jason Gerlowski wrote: >> >> Hey Eric, >> >> Sorry for the delay - I am hoping to review that PR. I'll try to have >> a review done by Monday (if not today). That should leave a week or >> so for any followups prior to your big trip! (Safe travels!) >> >> If Monday isn't early enough and you need to merge on Saturday, IMO >> that's fine. The PR's been open for nearly a year and you've been >> more than patient at this point. In that case I'll just review >> post-merge and we can handle any follow ups as needed. >> >> Best, >> >> Jason >> >> On Fri, Jun 21, 2024 at 12:07 PM Eric Pugh >> wrote: >>> >>> Hi all, I’m planning on merging https://github.com/apache/solr/pull/1768, >>> SOLR-16824: Adopt Linux Command line tool pattern of -- for long option >>> commands tomorrow (Saturday). >>> >>> I’m going to be traveling (Spain!) for three weeks starting June 29th, and >>> I’d like to make sure this fairly big change has plenty time for any >>> panicky follow up fixes that turn out to be needed when it goes into main >>> and branch_9x. >>> >>> Eric >>> >>> >>> ___ >>> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | >>> http://www.opensourceconnections.com >>> <http://www.opensourceconnections.com/> | My Free/Busy >>> <http://tinyurl.com/eric-cal> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed >>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >>> 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 >> > > ___ > Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com <http://www.opensourceconnections.com/> > | My Free/Busy <http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > 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 | OpenSource Connections, LLC | 434.466.1
Re: Integration test failures on Jenkins
Houston, did you make any progress on this? If this keeps happening, do we need to make our bats tests more robust in "checking" to see if a port is available first? On 2024/06/12 05:45:08 David Smiley wrote: > Thanks for investigating. The nature of the failure would never occur in a > contained infrastructure. It’s sad to see having to deal with this. Do you > know if it’s even an option to run a particular job in a container? > Anyway, reach infra on Slack #askinfra > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, Jun 11, 2024 at 6:42 PM Houston Putman wrote: > > > Currently the integration tests have been failing on Jenkins since around > > May 29th. It looks like there is a rogue process that has Auth enabled that > > is causing this problem. (Port 38603) > > > > For some reason a lot of the bin/solr commands choose to connect to this > > process instead of the SOLR_PORT that is in use by the integration tests at > > that point. I have a PR for making all commands in bin/solr use the same > > port defaulting, but that can really only land in 10.0. > > > > In the meantime we should see if infra can stop that rogue process so that > > the tests can start passing. > > > > - Houston > > > - To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
Re: Looking for final review of SOLR-16842
Thanks Jason, I’m happy to stall till end of day on Monday to click “merge”! Thanks. > On Jun 21, 2024, at 12:33 PM, Jason Gerlowski wrote: > > Hey Eric, > > Sorry for the delay - I am hoping to review that PR. I'll try to have > a review done by Monday (if not today). That should leave a week or > so for any followups prior to your big trip! (Safe travels!) > > If Monday isn't early enough and you need to merge on Saturday, IMO > that's fine. The PR's been open for nearly a year and you've been > more than patient at this point. In that case I'll just review > post-merge and we can handle any follow ups as needed. > > Best, > > Jason > > On Fri, Jun 21, 2024 at 12:07 PM Eric Pugh > wrote: >> >> Hi all, I’m planning on merging https://github.com/apache/solr/pull/1768, >> SOLR-16824: Adopt Linux Command line tool pattern of -- for long option >> commands tomorrow (Saturday). >> >> I’m going to be traveling (Spain!) for three weeks starting June 29th, and >> I’d like to make sure this fairly big change has plenty time for any panicky >> follow up fixes that turn out to be needed when it goes into main and >> branch_9x. >> >> Eric >> >> >> ___ >> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com <http://www.opensourceconnections.com/> >> | My Free/Busy <http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed >> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> 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 > ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Looking for final review of SOLR-16842
Hi all, I’m planning on merging https://github.com/apache/solr/pull/1768, SOLR-16824: Adopt Linux Command line tool pattern of -- for long option commands tomorrow (Saturday). I’m going to be traveling (Spain!) for three weeks starting June 29th, and I’d like to make sure this fairly big change has plenty time for any panicky follow up fixes that turn out to be needed when it goes into main and branch_9x. Eric ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Simplify Ref Guide Examples by Merging Windows and Mac/Linux Examples?
Thanks all, I created https://issues.apache.org/jira/browse/SOLR-17336 to track this. > On Jun 14, 2024, at 3:17 PM, Jan Høydahl wrote: > > +1 > > I have done this myself with paths when running java on Windows - easier to > handle forward/slash, less escaping etc. > > PS: I still hope we can remove bin\solr.cmd from 10.0 (but keep support for > Windows paths etc in Java). > > Jan > >> 14. juni 2024 kl. 19:30 skrev David Smiley : >> >> +1 >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Fri, Jun 14, 2024 at 3:30 PM Eric Pugh >> wrote: >> >>> In the ref guide we duplicate all out bin/solr post examples to deal with >>> the / for unix/Mac and \ for windows. >>> >>> I asked ChatGPT about this, and it said that Java just deals with it… >>> >>> I was thinking we could reduce the duplication by just providing the linux >>> example, and not labeling it “Linux/Mac” and not having a separate windows >>> one… >>> >>> Thoughts? >>> >>> Eric >>> >>> >>> What ChatGPT said: >>> In Java, the file path handling is designed to be platform-independent, so >>> a path like example/films/films.json will generally work on both Unix-based >>> systems (like Linux or macOS) and Windows, regardless of the underlying >>> file system conventions. >>> >>> Java's File class, which is used to interact with the file system, >>> automatically handles the differences in path separators between platforms. >>> On Unix-based systems, the path separator is the forward slash (/), while >>> on Windows, it's the backslash (\). >>> >>> When you pass a path like example/films/films.json to Java, it will >>> interpret the path correctly on both platforms. On Windows, Java will >>> automatically convert the forward slashes to backslashes as needed. >>> >>> Similarly, if you pass a Windows-style path like example\films\films.json, >>> Java will also handle that correctly on both Unix-based systems and Windows. >>> >>> The key point is that Java abstracts away the differences in file system >>> conventions between platforms, allowing your code to work consistently >>> across different operating systems. As long as you use Java's file system >>> APIs (such as File, Path, or Paths), you don't need to worry about the >>> underlying path separator characters. >>> >>> ___ >>> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | >>> http://www.opensourceconnections.com < >>> http://www.opensourceconnections.com/> | My Free/Busy < >>> http://tinyurl.com/eric-cal> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >>> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >>> >>> 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 > ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Simplify Ref Guide Examples by Merging Windows and Mac/Linux Examples?
In the ref guide we duplicate all out bin/solr post examples to deal with the / for unix/Mac and \ for windows. I asked ChatGPT about this, and it said that Java just deals with it… I was thinking we could reduce the duplication by just providing the linux example, and not labeling it “Linux/Mac” and not having a separate windows one… Thoughts? Eric What ChatGPT said: In Java, the file path handling is designed to be platform-independent, so a path like example/films/films.json will generally work on both Unix-based systems (like Linux or macOS) and Windows, regardless of the underlying file system conventions. Java's File class, which is used to interact with the file system, automatically handles the differences in path separators between platforms. On Unix-based systems, the path separator is the forward slash (/), while on Windows, it's the backslash (\). When you pass a path like example/films/films.json to Java, it will interpret the path correctly on both platforms. On Windows, Java will automatically convert the forward slashes to backslashes as needed. Similarly, if you pass a Windows-style path like example\films\films.json, Java will also handle that correctly on both Unix-based systems and Windows. The key point is that Java abstracts away the differences in file system conventions between platforms, allowing your code to work consistently across different operating systems. As long as you use Java's file system APIs (such as File, Path, or Paths), you don't need to worry about the underlying path separator characters. ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Heads up on SOLR-16824: Adopt Linux Command line tool pattern of -- for long option commands
I appreciate the encouragement Houston, I was starting to flag a bit on this… One thing I noticed is that some of our tools, like the ZK related ones, use the shell code to do arg parsing, and then we pass them into Java. Those will still work with old and new parameters, but until we move the logic into Java, you won’t get the deprecation messages. For example “bin/solr zk ls /blah/blah” doesn’t care that the path parameter went from “-path” to “—path” in the Java code ;-). Honestly, for those, I’m not sure how we remove the special arg parsing and just rely on commons-cli, and so is out of scope of this PR. > On Jun 12, 2024, at 10:25 AM, Houston Putman wrote: > > Thanks for doing the hard work eric! > > I think that's fine for the ref guide. > > - Houston > > On Wed, Jun 12, 2024 at 7:19 AM Eric Pugh <mailto:ep...@opensourceconnections.com>> > wrote: > >> I talked to Jason G a bit yesterday about “do we need to support all the >> renamed options as deprecations” and his thought was yes.. that scripts >> etc that use bin/solr shouldn’t break from 9.6 to 9.7… >> >> Sigh. >> >> So, I’m going to add in all the old deprecated options. For example, on >> the “upconfig” command we have a “-confdir” parameter in 9.6, and in 9.7 it >> will be “—confider”, but the old one will still work. You do get a warning >> that the command is deprecated which is nice. >> >> Then, in main I will remove all the old deprecated options, so we’ll slim >> down the code base… >> >> For the Solr Ref Guide, I plan on just updating it to the non deprecated >> commands and back porting it to 9.x branch of the docs…. >> >> Thoughts? >> >> Eric >> >> ___ >> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >> 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 | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: CHANGES.txt -- is worthy?
I definitly struggle with this. I wonder if we need a brand new approach that
isn’t encumbered by historical patterns to get us moving forward on this?
What if we changed it to something that focused on the different constituencies
of Solr.
* Changes Impacting Search Developers
* Changes Impacting Solr Operations Folks
* Changes Impacting Developers of Apache Solr
And maybe we pull the source information from the Github commit logs, Github
issues (if any), and the JIRA tickets and have someone just write it up? Heck,
I bet you paste all the text into GPT and it’ll give you a nice summary…. Add
that as a script.
If we want something more detail oriented, then we could machine generate a
dump of stuff and let users just go through it.
Maybe even a CHANGES.txt that is human written, and then CHANGES_9_7.txt that
is the machine dumped stuff.
David, I do appreciate your pushing forward on this…. Whatever we do, I hope we
document in our dev-docs/ what the expectations are for documenting changes so
the current folks and future committers all have something to reference ;-).
How can we move from bike shedding CHANGES.txt to something more concrete?
> On Jun 13, 2024, at 4:35 AM, David Smiley wrote:
>
> When I think of CHANGES.txt, I think of communicating to users. We
> write something succinct for the benefit of users to understand how
> this change will impact them.
>
> I don't think of CHANGES.txt as a log of all changes. I think
> increasing the scope to such wastes the time of users (and *we* are
> also users!), and dilutes the value of more meaningful entries.
>
> I know we have an "Other" section... perhaps this section allows us to
> add stuff that no user ought to care about. Not sure if users know to
> not waste their time looking at it. Still... I think we shouldn't
> bother adding some changes to CHANGES.txt at all.
>
> So... if a deprecated method is replaced with an equivalent... lets
> just not add this; okay? Specific example: replacing new URL("...")
> with the new equivalent. Honestly I don't even need to ask; just
> don't. Perhaps others have input on other examples or have different
> perspectives of thinking about this. The presence of a JIRA issue
> doesn't necessarily mean a CHANGES.txt entry needs to be added.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
___
Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 |
http://www.opensourceconnections.com <http://www.opensourceconnections.com/> |
My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
<https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
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.
Heads up on SOLR-16824: Adopt Linux Command line tool pattern of -- for long option commands
I talked to Jason G a bit yesterday about “do we need to support all the renamed options as deprecations” and his thought was yes.. that scripts etc that use bin/solr shouldn’t break from 9.6 to 9.7… Sigh. So, I’m going to add in all the old deprecated options. For example, on the “upconfig” command we have a “-confdir” parameter in 9.6, and in 9.7 it will be “—confider”, but the old one will still work. You do get a warning that the command is deprecated which is nice. Then, in main I will remove all the old deprecated options, so we’ll slim down the code base… For the Solr Ref Guide, I plan on just updating it to the non deprecated commands and back porting it to 9.x branch of the docs…. Thoughts? Eric ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: CI builds for older Solr releases linger... why?
David, I went to look at the builds and the long list is rather overwhelming! So +1 to pruning. On 2024/06/04 19:53:14 David Smiley wrote: > I suspect nobody was reading the conversation Eric and I were having > on bui...@solr.apache.org; maybe because nobody looks there. Maybe we > should never do that and have it be build-only messages. Nevertheless > all active Solr committers should subscribe to that list if you > haven't (it's a basic project hygiene thing -- monitor builds). So I > am copy-pasting to our dev list. > > I will very soon take action to DELETE (not disable) the Jenkins CI > builds for 8.9, 8.10 (not 8.11), 9.0, 9.1, 9.2, 9.3, 9.4, 9.5 -- there > are more than one jobs for some of these releases. Our ref guide > instructions actually indicate to do this: > https://cwiki.apache.org/confluence/display/SOLR/JenkinsReleaseBuilds+-+Solr > so I won't wait for someone to tell me not to follow these > instructions ;-). Yet release after release, nobody has done this > despite this being a release-wizard step (AFAICT). What's broken in > our process here folks? (Don't ask me, I only did a *patch* release > once which has no step to do here.) > > ~ David > > -- Forwarded message - > From: David Smiley > Date: Fri, May 31, 2024 at 11:14 AM > Subject: Re: [JENKINS] Solr » Solr-Smoketest-9.4 - Build # 284 - Still > Failing! > To: , Gus Heck , > > Cc: Eric Pugh , > > > I don't think we need release jobs for older releases -- older than > the latest. Our release process refers RMs to visit > https://cwiki.apache.org/confluence/display/SOLR/JenkinsReleaseBuilds+-+Solr > which first instructs to remove old jobs. I think this only happens > for major/minor releases but not patch releases. > > https://ci-builds.apache.org/job/Solr/ > > Gus, you did 9.6.0. Did the release wizard direct you to > https://cwiki.apache.org/confluence/display/SOLR/JenkinsReleaseBuilds+-+Solr > ? > Jason, you did 9.5.0. Same question. > > > On Fri, May 31, 2024 at 8:45 AM Eric Pugh > wrote: > > > > At first blush, running locally things are fine…. > > > > Is there any chance that the various Jenkins jobs could be > > sharing/communicating across each other where a bad running Solr instance > > in main is still there and causing others to fail? I ask because why would > > 9.1, 9.3, 9.4, 9.5, 9.6 all start failing between 3 days and 10 hours ago > > and 2 days 9 hours ago? I get changes on 9.6, but not on the previous > > versions. > > > > > > > > > > > > > > > On May 31, 2024, at 8:19 AM, Eric Pugh > > > wrote: > > > > > > Looks like it’s failing in 9x too. I’ll check out what’s going on. > > > > > > What is our policy for having older tests…. Do we actually need to keep > > > around the checks for 9.0 through 9.5? If we found a major issue in a > > > previous release like 9.2, would we just ship an updated 9.x, so it would > > > be a 9.6.2 or a 9.7? > > > > > > Wondering if having fewer Jenkins jobs would make it easier to keep tabs > > > on them? > > > > > > > > >> On May 31, 2024, at 1:33 AM, David Smiley wrote: > > >> > > >> Eric, maybe you were working on authentication matters and could thus > > >> guess as to why some smoke tests fail here? This one is for 9.4 but > > >> there's another for 9.6 > > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
Re: CI build failures
I think a weekly heads up would be great to have. You mention “PR validation doesn’t run BATS tests”…. Maybe it should? We’ve had a lot of churn in the CLI, and we’ll probably continue to have that till 10x comes out, so that would be a nice check. Plus, if we add more integration style BATS tests, why not have them be run on the PR’s? > On May 31, 2024, at 11:40 AM, David Smiley wrote: > > I'm concerned that too few people look at the bui...@solr.apache.org > From time to time I go look but we have no notifications other than > emailing that list. > > If hypothetically nobody looked, we might as well not have CI at all; > we'd only have PR based validation. We'd lose out on historic test > failure tracking and detection of introducing a problem that got > merged anyway. PR validation doesn't run BATS tests or "Nightly" > tests. > > Long ago, I recall getting a direct email to me if I contributed a > change to a CI failure. I would like this. I would also like a dev > list email periodically (weekly?) listing the CI job status. > > Any opinions on what to do here? > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Seeking guidance on Upgrading Minimum Java Version for Main Branch
We are currently blocked from the latest OpenNLP because they moved to newer Java. You may be interested in https://github.com/apache/solr/pull/1510 and https://github.com/apache/solr/pull/1999. I’d love to see us starting to learn about what impacts Java 17 has. I suspect once Lucene 10 starts getting ready, it may encourage us to rush a bit to get Solr 10 out the door.. > On Jun 4, 2024, at 4:18 AM, Jan Høydahl wrote: > > Hi, > > Thanks for starting the topic. Looks like we'll align Solr 10 with Lucene 10, > so somewhere between now and the release of Lucene 10 we definitely should > make the same move. > Our typical concern is if the change causes lots of other code changes that > makes backporting harder for a prolonged period. That speaks for waiting, > since our 10.0 release won't be until the end of year anyway. > > A good timing for our cutover could be once the Lucene project starts > preparing for a 10.0 release. We could then switch Solr main to using a > nighlty lucene main build and start implementing new and changes APIs. > > However, if bumping min Java version for main won't cause much fuzz (i.e. we > could delay doing sweeping codebase changes for new language features), I'm > not opposed to doing the change sooner. > > Jan > >> 4. juni 2024 kl. 07:46 skrev sanjay dutt >> : >> >> The purpose of this email thread is to initiate a discussion about upgrading >> the minimum Java version (Could be same as Lucene minimum Java for main >> branch i.e. 21) for the main branch. We seek to understand the community's >> major concerns and gather their guidance on this matter. >> Regards,Sanjay > > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Found a bug in 9.6...
Agreed! I won’t be able to fix it for a day or so… On Wed, May 29, 2024 at 4:33 PM Anshum Gupta wrote: > +1 to continue with the 9.6.1 release. > > On Wed, May 29, 2024 at 12:50 PM Houston Putman > wrote: > > > Honestly there are some pretty bad bugs that 9.6.1 is aiming to fix, so > > I'm hesitant to fail the RC for this. If you have a quick fix, I can > make a > > new RC, but otherwise I'd likely just leave it for 9.6.2 or 9.7.0. > > > > These releases aren't hard to do, we can always do another one in a few > > weeks. > > > > - Houston > > > > On Wed, May 29, 2024 at 1:15 PM Eric Pugh < > ep...@opensourceconnections.com> > > wrote: > > > >> I don’t know that it’s worth holding up 9.6.1 for…. > >> > >> > >> [SOLR-17315] Bug in messaging when creating a collection, and then you > >> can't actually call the config method to set-user-property - ASF JIRA > >> <https://issues.apache.org/jira/browse/SOLR-17315> > >> issues.apache.org <https://issues.apache.org/jira/browse/SOLR-17315> > >> [image: fav-jsw.png] <https://issues.apache.org/jira/browse/SOLR-17315> > >> <https://issues.apache.org/jira/browse/SOLR-17315> > >> > >> It started as just a bug in the messaging from bin/solr create -c > >> mycollection, but found that the bin/solr config -c mycollection -action > >> set-user-property -property update.autoCreateFields -value false > >> > >> Is failing….Works on main ;-( > >> > >> ___ > >> *Eric Pugh **| *Founder | OpenSource Connections, LLC | 434.466.1467 | > >> http://www.opensourceconnections.com | My Free/Busy > >> <http://tinyurl.com/eric-cal> > >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > >> < > https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw > > > >> 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. > >> > >> > > -- > Anshum Gupta >
Found a bug in 9.6...
I don’t know that it’s worth holding up 9.6.1 for…. https://issues.apache.org/jira/browse/SOLR-17315 It started as just a bug in the messaging from bin/solr create -c mycollection, but found that the bin/solr config -c mycollection -action set-user-property -property update.autoCreateFields -value false Is failing….Works on main ;-( ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: SIP-18: A Solr Kubernetes Module for native integration
We need a complete path for scaling from the smallest Solr set ups to the largest that is well supported by the community, and this seems to be key to supporting the largest deployments. So this make sense to me. Would saying that this kind of change is targeting Solr 10 take some of the pressure off of us? Our normal pattern of back porting everything to the current branch means that every code change has to be in a releasable state, which maybe leads to more discussion. If this is 10x, then maybe less pressure? I guess this is really up to whoever or group of whoever decide to move this forward ;-). > On May 28, 2024, at 5:53 AM, Jan Høydahl wrote: > > I think of this from time to time. To get some progress, should be first > agree in this thread that it is a decent idea, and that a new Solr module is > warranted for this? > > I'd hate to see good initatives like this to he held up by arguments not > related to the code itself but to the lifecycle or wish for separate git > repos etc. > > Once we agree to move forward, the JIRA could be split up into manageable > tasks that more community members could help with. > > Jan > > On 2023/04/05 16:45:26 Houston Putman wrote: >> Hey everyone, >> >> This is a new SIP, not a duplicate of SIP-17 (Authoscaling on Kubernetes), >> and completely unrelated. >> >> Basically there is a lot of very messy logic we do in the Solr Operator to >> bootstrap security and manage various things. This logic must exist because >> Solr has no idea that Kubernetes exists. >> If we can use Kubernetes APIs to pull in information, instead of relying on >> the Solr Operator to inject that information in hacky-ways, the user >> experience on Kubernetes is going to get many times better for users >> wanting to secure their SolrClouds. This will also help us use >> authorization by default (which we always preach) via the Solr Operator. >> >> This SIP is not very filled out because I'm still thinking on various >> aspects. But in general, we can attack the different plugins one-by-one and >> the SIP can evolve throughout the process. This SIP is very easy to break >> up, which is nice. >> >> Please let me know if I can explain more, or how I can make the SIP page >> better. >> >> - Houston >> > > ----- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Welcome Sanjay Dutt as Solr committer!
Welcome!Let’s get that HTTP2 migration done! > On May 20, 2024, at 6:04 PM, Alex Deparvu wrote: > > Congratulations Sanjay! > > > > On Mon, May 20, 2024 at 14:12 Anshum Gupta wrote: > >> Congratulations and welcome, Sanjay! >> >> On Mon, May 20, 2024 at 11:59 AM Ilan Ginzburg wrote: >> >>> Welcome Sanjay and congrats! >>> >>> On Mon, May 20, 2024 at 8:46 PM Jason Gerlowski >>> wrote: >>> >>>> Welcome and congratulations! >>>> >>>> On Mon, May 20, 2024 at 2:04 PM Ishan Chattopadhyaya >>>> wrote: >>>>> >>>>> Welcome Sanjay. Many congratulations! >>>>> >>>>> On Mon, 20 May, 2024, 9:53 pm David Smiley, >>> wrote: >>>>> >>>>>> The Project Management Committee (PMC) for Apache Solr has invited >>>>>> Sanjay Dutt to become a committer and we are pleased to announce >> that >>>>>> they have accepted. >>>>>> >>>>>> Sanjay, the tradition is that new committers introduce themselves >>> with >>>>>> a brief bio. >>>>>> >>>>>> Congratulations and welcome! >>>>>> >>>>>> >> - >>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>> >>>>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>> >>>> >>> >> >> >> -- >> Anshum Gupta >> ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: CHANGES.txt, process improvement solicitation
I *do* find our current situation the worst of all possible options! > On May 16, 2024, at 2:51 PM, David Smiley wrote: > > Managing CHANGES.txt in each PR/change we do is a pain. It's so > merge-conflict prone. I don't mean to call for the removal of > CHANGES.txt (although I've wished for this off-and-on), but want to > solicit inputs on what can be done to make this easier. > > I could be mistaken but maybe it was Calvin Cowie that recommended a > scheme something like the following: each change/PR merely adds its > own txt file to a new CHANGES directory instead of adding to > CHANGES.txt. Then it will be aggregated / concatenated to CHANGES.txt > at a release boundary by the RM using a script. The per-change file > then goes away. The category (e.g. New Feature vs Bug Fix) would need > to be encoded somewhere, like maybe in the file name. Even the JIRA > number could be part of the file name and not its content. No ad-hoc > newline use either; just write the message and the script will > line-wrap it. This is probably the simplest and least disruptive > change. > > I'm kind of envious of small projects that can simply rely on GitHub's > release notes generator [1]. Yeah it's just the first-line commit > message, which emphasizes brevity over clarity. > > [1] > https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: [DISCUSS] Community Virtual Meetup, May 2024
I vote for (2), (3). > On May 14, 2024, at 12:20 PM, Jason Gerlowski wrote: > > I'll vote for (2)! > > On Tue, May 14, 2024 at 1:47 AM raghavan m wrote: >> >> Hello everyone >> >> I am soliciting votes for the following days and times. Please reply to >> this thread with your preferred 1) *date and time options from below *and >> 2) *topic you want to discuss * >> >> *Voting closes May 17th 11:59 pm* >> >> *Options* >> 1. 05/22/2024 9 am pacific time >> 2. 05/23/2024 9 am pacific time >> 3. 05/24/2024 9 am pacific time >> 4. 05/27/2024 9 am pacific time >> >> thanks, >> *Raghavan* >> >> >> On Sun, May 12, 2024 at 7:03 PM raghavan m wrote: >> >>> Thanks Jason. >>> I will start a thread and create a page, to collect topics. >>> *Raghavan* >>> >>> >>> On Sun, May 12, 2024 at 7:00 PM Jason Gerlowski >>> wrote: >>> >>>> Raghavan - absolutely, thanks for stepping up! (And welcome back to >>>> the country!). >>>> >>>> On Thu, May 9, 2024 at 1:51 PM raghavan m wrote: >>>>> >>>>> Hey Jason >>>>> I am back in the country. Can I volunteer? >>>>> >>>>> Sent from iPhone >>>>> >>>>> >>>>> On Thu, May 9, 2024 at 9:35 AM Jason Gerlowski >>>>> wrote: >>>>> >>>>>> Hey all, >>>>>> >>>>>> It's time once again to start thinking ahead to this month's virtual >>>>>> meetup! >>>>>> >>>>>> As always, two questions: >>>>>> >>>>>> 1. Does anyone have an interest in organizing? Duties are light but >>>>>> it's an important job. I'm happy to organize by default if there >>>>>> aren't any volunteers by mid-next-week. (Addtl details: >>>>>> https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes) >>>>>> >>>>>> 2. Does anyone have preferences on the date or time-of-day? >>>>>> >>>>>> Best, >>>>>> >>>>>> Jason >>>>>> >>>>>> - >>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>> >>>>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>> >>>> > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: SolrJ HTTP SolrClient class hierarchy
That makes sense. It might be interesting at our next community meet up to bring up some of these “umbrella” tickets and socialize them around, to activate some folks! > On Apr 30, 2024, at 9:21 AM, Jan Høydahl wrote: > > There is an umbrella issue for major SolrJ changes > https://issues.apache.org/jira/browse/SOLR-15730. Some of the sub tasks are > 10.0 only. Could add a rename jira there? > > Jan > >> 30. apr. 2024 kl. 15:04 skrev Eric Pugh > <mailto:ep...@opensourceconnections.com>>: >> >> Please! It would be nice if someone laid out the work to be done in some >> tickets so folks could pick it up…. Otherwise it looks a bit daunting! >> >>> On Apr 30, 2024, at 7:38 AM, Jan Høydahl wrote: >>> >>> In Solr 10, SolrJ will have new maven coordinates and the need to >>> explicitly pull in solrj-xx dependencies. So we coult also do a few key >>> renames such as "Http2SolrClient" -> "HttpJettySolrClient", while we're >>> busy breaking things :) >>> >>> Jan >>> >>>> 30. apr. 2024 kl. 13:21 skrev Jason Gerlowski : >>>> >>>> Thanks for summarizing this all David! >>>> >>>> We have HttpSolrClientBase AND BaseHttpSolrClient?! >>>> >>>> A bit of the messiness here seems like it will resolve itself >>>> "automatically" if we make good on removing the existing deprecations. >>>> (Though given how "entrenched" the Apache client is, that will require >>>> a good bit of work...). >>>> >>>> I like the convention established by the JDK client, of naming our >>>> low-level SolrClient implementations based on the HttpClient vendor in >>>> use. IMO doing otherwise can be confusing in a few different ways. >>>> It's not high on my list to act on it immediately, but if there's >>>> enough consensus on the idea of renaming (e.g.) Http2SolrClient, I >>>> could file a ticket to document that as an ideal step and maybe it'll >>>> hook someone eventually? >>>> >>>> Best, >>>> >>>> Jason >>>> >>>> On Thu, Apr 25, 2024 at 11:34 PM Mark Miller wrote: >>>>> >>>>> It's too bad HttpSolrServer setup this client philosophy. It's momentum >>>>> was directly opposite to what you want: a SolrClient that can optionally >>>>> stream or load balance and a SolrCloudClient that wraps it. >>>>> >>>>> [Mark Miller - Chat @ >>>>> Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=2kigx5) >>>>> [2kigx5] >>>>> >>>>> On April 25, 2024 at 20:07 GMT, David Smiley wrote: >>>>> >>>>> Our SolrJ class hierarchy is looking rather confusing right now for >>>>> the HTTP ones especially. This message is mostly a big FYI, with some >>>>> reflections and a recommendation or two. >>>>> >>>>> SolrClient >>>>> - BaseHttpSolrClient (NOT yet deprecated but should be?) >>>>> - - HttpSolrClient (based on Apache HttpClient; deprecated) >>>>> - - - DelegationTokenHttpSolrClient >>>>> - CloudSolrClient >>>>> - - CloudHttp2SolrClient >>>>> - - CloudLegacySolrClient (based on Apache HttpClient; deprecated) >>>>> - ConcurrentUpdateHttp2SolrClient >>>>> - - ... >>>>> - ConcurrentUpdateSolrClient (based on Apache HttpClient; deprecated) >>>>> - - ... >>>>> - HttpSolrClientBase (this is new) >>>>> - - Http2SolrClient >>>>> - - HttpJdkSolrClient (this is new; based on the JDK HttpClient) >>>>> - LBSolrClient >>>>> - - LBHttp2SolrClient >>>>> - - LBHttpSolrClient (based on Apache HttpClient; deprecated) >>>>> >>>>> In retrospect, we can see that some past names weren't so great after >>>>> all. I think our clients should reflect the vendor/source of the >>>>> HttpClient. "HttpJdkSolrClient" is the newest client, and it reflects >>>>> the vendor (JDK provided HttpClient). Personally I don't care enough >>>>> to rename all the ones with "2" in there to have "Jetty" but that's >>>>> what they are -- if it has a "2", it's using Jetty (and it supports >>>>> 1.1; FYI JDK also supports both 1.1 and 2 as well). The clients for &
Re: SolrJ HTTP SolrClient class hierarchy
gt;> references, after which we can finally free users of needing those >>> dependencies. >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>> For additional commands, e-mail: dev-h...@solr.apache.org >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Tracking contributors uniquely
I’d like to have both committers and contributers included, not just contributors. If it’s just contributors, and the list is short, then it may appear we have a very small community ;-). I do like the idea of thanking folks! > On Apr 26, 2024, at 9:45 PM, Chris Hostetter wrote: > > > : LOL meanwhile I posted https://github.com/apache/solr/pull/2424 for > : the script I developed and improved today. > : I think CHANGES.txt is the best source for a release centric view > : while git log is best for project health metrics. > > Agreed. People are frequently mentioned in CHANGES because they > contributed to the *issue* even when they didn't contribute to the *code* > (ie: reported & diagnosed a bug, aided in design discussions, etc..) > > A script to use git commit data to help create CHANGES entries (or look > for CHANGES entries that are missing credit) seems like a good sanity > check to ensuring nothing trivial is overlooked in CHANGES. > > A script to generate a thank you list of contributors should be based on > the list of contributors from CHANGES (regardless of how they got there) > > > > : On Fri, Apr 26, 2024 at 4:38 PM Jan Høydahl wrote: > : > > : > I think it is a good idea to include a list of contributors in the > release note mail. > : > it is a tiny encouragement for folks to contribute more. The list should > perhaps > : > be excluding committers, so we only list external contributors? > : > > : > I already added a script to dev-tools to parse SolrBot contributions from > git log and add to CHANGES: > : > > https://github.com/apache/solr/blob/main/dev-tools/scripts/addDepsToChanges.py > : > > : > Based on this I did a similar script that parses out Authors and > Co-Authored-By from git log > : > since last release, see https://github.com/apache/solr/pull/2423 for a > Draft. > : > > : > There's a risk of this method missing the names of some contributors who > did not actually commit anything to a PR but still are listed in CHANGES for > the release. That can be fixed by us being more careful when merging PRs, and > when committing patches from JIRA, > : > > : > Jan > : > > : > > 26. apr. 2024 kl. 15:39 skrev David Smiley : > : > > > : > > On Fri, Apr 26, 2024 at 9:35 AM Gus Heck wrote: > : > >> > : > >> I don't know if it's relevant, but I recall that back in the early > 2000's > : > >> around the time of the adoption of the ASL 2.0 (when I was > contributing to > : > >> Ant) the ASF had us stop using @author tags in code. I was not a fan > at the > : > >> time, but they had some reason I don't fully recall relating to > shielding > : > >> the contributors in the event of someone hitting a bug and then trying > to > : > >> sue folks to recover losses or something. I wonder if that logic still > : > >> exists, and if this could be seen as related to that. It's also > possible > : > >> that this memory has severely mutated while hanging out in the back of > my > : > >> brain for 20 year :). > : > > > : > > The context of the name appearing as I propose in a "thank you" is > : > > merely to thank them, not to indirectly hold them to stability/quality > : > > measures. > : > > > : > > I don't think it's related. @author tags can repel a collaborative > : > > ownership mindset on a specific bit of code. I used to @author my > : > > code out of pride but long ago I realized those tags are a bad idea > : > > and also kind of needless with git-blame anyway. > : > > > : > > - > : > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > : > > For additional commands, e-mail: dev-h...@solr.apache.org > : > > > : > > : > : - > : To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > : For additional commands, e-mail: dev-h...@solr.apache.org > : > : > > -Hoss > http://www.lucidworks.com/ > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Tracking contributors uniquely
I like it! > On Apr 26, 2024, at 9:39 AM, David Smiley wrote: > > On Fri, Apr 26, 2024 at 9:35 AM Gus Heck wrote: >> >> I don't know if it's relevant, but I recall that back in the early 2000's >> around the time of the adoption of the ASL 2.0 (when I was contributing to >> Ant) the ASF had us stop using @author tags in code. I was not a fan at the >> time, but they had some reason I don't fully recall relating to shielding >> the contributors in the event of someone hitting a bug and then trying to >> sue folks to recover losses or something. I wonder if that logic still >> exists, and if this could be seen as related to that. It's also possible >> that this memory has severely mutated while hanging out in the back of my >> brain for 20 year :). > > The context of the name appearing as I propose in a "thank you" is > merely to thank them, not to indirectly hold them to stability/quality > measures. > > I don't think it's related. @author tags can repel a collaborative > ownership mindset on a specific bit of code. I used to @author my > code out of pride but long ago I realized those tags are a bad idea > and also kind of needless with git-blame anyway. > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Is SolrBot too noisy / being ignored...?
Ah.. So we don’t quite yet know how to deal with the aws and google libraries being constantly updated? It looks like SolrBot opened PR’s get the “dependency” label added. I looked in Github PR’s, https://github.com/apache/solr/pulls?page=2=is%3Apr+is%3Aopen+label%3Adependencies and the list isn’t too long.. There are a few candidates that look like they passed tests and are straightforward to merge... We are still putting these changes into solr/CHANGES.txt under Dependencies right? > On Apr 20, 2024, at 11:56 AM, Jan Høydahl wrote: > > The bot does not have and will not have commit rights. And if it auto merged > it would only be main branch, and a committer would need to handle 9x anyway. > > I still think the right medicine for aws and google deps is to open prs less > frequently, if we find the right config spell in renovate. > > I use the cherrypick script to backport to 9.x after merge, is very little > overhead. > > Jan Høydahl > >> 19. apr. 2024 kl. 22:46 skrev David Smiley : >> >> I think it’s satisfactory if we merely have advice to ourselves in the PR >> to remind us what little we need to do. Like… if you are a committer and >> this is passing, just merge it. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >>> On Fri, Apr 19, 2024 at 7:51 AM Eric Pugh >>> wrote: >>> >>> From the perspective of commits being merged by a bot? >>> >>> Assuming the legal side was okay, what are your thoughts about having the >>> commits be merged by a bot based on the criteria I suggested? Crazy? >>> Reasonable? >>> >>> >>> >>>>> On Apr 18, 2024, at 7:00 PM, Mike Drob wrote: >>>> >>>> That’s probably a question for asf legal >>>> >>>> On Thu, Apr 18, 2024 at 5:36 PM Eric Pugh < >>> ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com>> >>>> wrote: >>>> >>>>> Thanks for the work that has been done on some of these. >>>>> >>>>> I actually just ran through the process of updating commons-cli based on >>>>> what SolrBot provided. I *did* have to update a Java class, and I did >>>>> regenerate the licenses, and that was about it… >>>>> >>>>> Which made me wonder.. If SolrBot opens a dependency upgrade, and >>>>> recommit and the tests pass, could we have it just commit automatically >>> the >>>>> update? >>>>> >>>>> I looked at one that I constantly see, the update to the awssdk: >>>>> https://github.com/apache/solr/pull/2056. The tests all pass, and it >>>>> appears all I need to do to make precommit happy is drop in some new >>>>> licenses. Other than that, I believe that I could merge that PR, and I >>>>> wouldn’t need to do any other steps…. So, if there were no new license >>> and >>>>> precommit had passed, couldn’t SolrBot merge it for us? >>>>> >>>>> Basically, do we actually need a human in the loop on this when at least >>>>> this human, me, wouldn’t really be doing anything else if all the checks >>>>> passed…. >>>>> >>>>>> On Apr 9, 2024, at 8:01 AM, Eric Pugh >>> >>>>> wrote: >>>>>> >>>>>> The update that I see a lot is for the software.amazon.awssdk and >>>>> com.google.cloud packages…. I checked renovate.json and they should >>> only >>>>> happen once a month. >>>>>> >>>>>> I just checked and there has been an update today, yesterday, and the >>>>> day before for the software.amazon.awssdk package. >>>>>> >>>>>> Looks like they all go to https://github.com/apache/solr/pull/2056 >>>>> however. Is this because once it opens the PR, it is just updating the >>> PR >>>>> as needed? >>>>>> >>>>>> How can we get a smoother workflow? The constant updates are noisy, >>>>> and now I think they are just ignored…! I saw that Kevin approved this >>>>> back in November 2023. Do we want to be more on top of these and >>> merge as >>>>> they go? >>>>>> >>>>>> And maybe for these frequently changing ones, maybe move to a quarterly >>>>&
Re: [DISCUSS] Community Virtual Meetup, April 2024
I vote for 26th, or 29 or 30 ;-) > On Apr 17, 2024, at 12:42 PM, Jason Gerlowski wrote: > > Hey all, > > It's time once again to start thinking ahead to our Virtual Meetup for April! > > 1. Anyone have an interest in organizing? I'm happy to organize "by > default" if we don't have any volunteers by EOD Monday, but it's > always great to rotate! > > 2. When would we like to meet? > > Best, > > Jason > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Is SolrBot too noisy / being ignored...?
From the perspective of commits being merged by a bot? Assuming the legal side was okay, what are your thoughts about having the commits be merged by a bot based on the criteria I suggested? Crazy? Reasonable? > On Apr 18, 2024, at 7:00 PM, Mike Drob wrote: > > That’s probably a question for asf legal > > On Thu, Apr 18, 2024 at 5:36 PM Eric Pugh <mailto:ep...@opensourceconnections.com>> > wrote: > >> Thanks for the work that has been done on some of these. >> >> I actually just ran through the process of updating commons-cli based on >> what SolrBot provided. I *did* have to update a Java class, and I did >> regenerate the licenses, and that was about it… >> >> Which made me wonder.. If SolrBot opens a dependency upgrade, and >> recommit and the tests pass, could we have it just commit automatically the >> update? >> >> I looked at one that I constantly see, the update to the awssdk: >> https://github.com/apache/solr/pull/2056. The tests all pass, and it >> appears all I need to do to make precommit happy is drop in some new >> licenses. Other than that, I believe that I could merge that PR, and I >> wouldn’t need to do any other steps…. So, if there were no new license and >> precommit had passed, couldn’t SolrBot merge it for us? >> >> Basically, do we actually need a human in the loop on this when at least >> this human, me, wouldn’t really be doing anything else if all the checks >> passed…. >> >>> On Apr 9, 2024, at 8:01 AM, Eric Pugh >> wrote: >>> >>> The update that I see a lot is for the software.amazon.awssdk and >> com.google.cloud packages…. I checked renovate.json and they should only >> happen once a month. >>> >>> I just checked and there has been an update today, yesterday, and the >> day before for the software.amazon.awssdk package. >>> >>> Looks like they all go to https://github.com/apache/solr/pull/2056 >> however. Is this because once it opens the PR, it is just updating the PR >> as needed? >>> >>> How can we get a smoother workflow? The constant updates are noisy, >> and now I think they are just ignored…! I saw that Kevin approved this >> back in November 2023. Do we want to be more on top of these and merge as >> they go? >>> >>> And maybe for these frequently changing ones, maybe move to a quarterly >> schedule? Or, do we add it to the release manager process, though I know >> that approach was discussed and then viewed as too burdensome for the RM. >>> >>> >>> >>> Eric >>> >>> >>> >>> >>> >>> ___ >>> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >>> 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 | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com <http://www.opensourceconnections.com/> >> < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >> 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 | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Is SolrBot too noisy / being ignored...?
Thanks for the work that has been done on some of these. I actually just ran through the process of updating commons-cli based on what SolrBot provided. I *did* have to update a Java class, and I did regenerate the licenses, and that was about it… Which made me wonder.. If SolrBot opens a dependency upgrade, and recommit and the tests pass, could we have it just commit automatically the update? I looked at one that I constantly see, the update to the awssdk: https://github.com/apache/solr/pull/2056. The tests all pass, and it appears all I need to do to make precommit happy is drop in some new licenses. Other than that, I believe that I could merge that PR, and I wouldn’t need to do any other steps…. So, if there were no new license and precommit had passed, couldn’t SolrBot merge it for us? Basically, do we actually need a human in the loop on this when at least this human, me, wouldn’t really be doing anything else if all the checks passed…. > On Apr 9, 2024, at 8:01 AM, Eric Pugh wrote: > > The update that I see a lot is for the software.amazon.awssdk and > com.google.cloud packages…. I checked renovate.json and they should only > happen once a month. > > I just checked and there has been an update today, yesterday, and the day > before for the software.amazon.awssdk package. > > Looks like they all go to https://github.com/apache/solr/pull/2056 however. > Is this because once it opens the PR, it is just updating the PR as needed? > > How can we get a smoother workflow? The constant updates are noisy, and now > I think they are just ignored…! I saw that Kevin approved this back in > November 2023. Do we want to be more on top of these and merge as they go? > > > And maybe for these frequently changing ones, maybe move to a quarterly > schedule? Or, do we add it to the release manager process, though I know > that approach was discussed and then viewed as too burdensome for the RM. > > > > Eric > > > > > > ___ > Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com <http://www.opensourceconnections.com/> > | My Free/Busy <http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > 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 | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: PR ready fro review
I put some comments in.On the V2 api, I think that if this is specific to a collection, then /api/collections/cluster-size or maybe even /api/collections/sizing If it’s overall, and not collection specific, then /api/cluster/sizing would make sense.And if it supports both, well then it could be both patterns! Jason G might have more insight on the best path…. > On Apr 8, 2024, at 5:02 PM, Isabelle Giguere > wrote: > > Hello committers; > > Please take some time to review this PR : > https://github.com/apache/solr/pull/1638 > > It is based on a rather old patch, so only V1 is supported, for now. > > If we wanted V2, what should be the URL path ? > > * > /api/collections/cluster-size > * > /api/cluster/sizing > > V2 could be handled in a different PR, if preferable. > > Thank you; > > Isabelle Giguère > Computational linguist & Java developer | Engineering > Linguiste informaticienne & développeur java | Engineering > > Phone: (514) 908 5406 ext. 75125 > Website:https://www.opentext.com/ > > > [https://mimage.opentext.com/alt_content/binary/images/email-signature/ot2023-corporate-email-signature-370x70-fy24-2-retina.png]<https://www.opentext.com/> > > This email message is confidential, may be privileged, and is intended for > the exclusive use of the addressee. Any other person is strictly prohibited > from disclosing or reproducing it. If the addressee cannot be reached or is > unknown to you, please inform the sender by return email and delete this > email message and all copies immediately. ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Is SolrBot too noisy / being ignored...?
The update that I see a lot is for the software.amazon.awssdk and com.google.cloud packages…. I checked renovate.json and they should only happen once a month. I just checked and there has been an update today, yesterday, and the day before for the software.amazon.awssdk package. Looks like they all go to https://github.com/apache/solr/pull/2056 however. Is this because once it opens the PR, it is just updating the PR as needed? How can we get a smoother workflow? The constant updates are noisy, and now I think they are just ignored…! I saw that Kevin approved this back in November 2023. Do we want to be more on top of these and merge as they go? And maybe for these frequently changing ones, maybe move to a quarterly schedule? Or, do we add it to the release manager process, though I know that approach was discussed and then viewed as too burdensome for the RM. Eric ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Can I get a LGTM on https://github.com/apache/solr/pull/2378 ? CloudSolrClient builder change..
Discovered a bug in how we set up CloudHttp2SolrClient with httpClient builder while debugging Export Tool + Basic Auth. Would love a second set of eyes. Eric ___ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Solr Architecture that scales from Hello World to Cloud Native Scale
I wanted to share a diagram more widely that I’ve shared with some folks, but maybe not everyone, on where my head is with our approach to scaling Solr for all of our users. Since images don’t go through, you have to click this public Miro link ;-). https://miro.com/app/board/o9J_lm8BmXE=/?moveToWidget=3458764558006503531=14 I think that we have to figure out how to move forward with new ideas to maintain the vibrancy and vitality of our project. We have to be open to new ideas and new approaches, while still being able to bring along our user base. This diagram has been helpful to me in terms of thinking about “what capabilities does Solr need” for various parts of our user base. I’m very open to new ideas that take us beyond “SolrCloud”.. Is it time for the successor to that approach? Moving to an approach where you can run your simple setups, but also fairly seamlessly have that scale up to the Cloud Native scale? Without, as a user going through massive conceptual jumps and hurdles? Eric ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: DISCUSS: Optionality of JIRA issues
onitor the dev list daily but not the issues >>>> list (hey I have a day job LOL). I suspect new people interested in >>>> Solr development miss subscribing to that list. If you mean *after* a >>>> code change -- note the PR isn't closed for comments. I've commented >>>> on a PR after a merge to follow up. The participants to the PR >>>> (subscribers) should get notified. I've found it's increasingly rare >>>> for people to even "Watch" the JIRA issue if there is a PR >>>> accompanying it, making me wonder if whatever I write there will be >>>> read. >>>> >>>> When GitHub PRs with code review commentary was a new contribution >>>> approach for Solr, I had suggested at the time that JIRA issues be >>>> where we discuss the high level matter -- requirements and approach. >>>> In practice, once you start looking at the PR, you instinctively want >>>> to comment there no matter what level of detail; it's just natural. >>>> Not just for little things but bigger things (i.e. should we even be >>>> doing it this way?). Sometimes I've conversed back on the JIRA issue >>>> to discuss the bigger picture. >>>> >>>> Independently of the forthcoming vote thread, more could be done to >>>> make our use of JIRA better. For example, if we could get a weekly >>>> (or more often?) digest summary of what's happening in JIRA and post >>>> this to the dev list, I think it'd be very helpful to bring visibility >>>> there. And we could re-examine the JIRA-PR synchronization options >>>> that the ASF gives us. Originally it was configured for all >>>> individual updates to be copied to JIRA which was way too much but if >>>> it could be configured to be top level comments only, I think that'd >>>> be a nice balance. >>>> >>>> Nevertheless; if someone has a PR and doesn't want to create a JIRA; I >>>> don't blame them :-) >>>> >>>>> If people find that it really slows them down to create a jira, we >> can >>>>> create a catch-all jira per released Solr version, referenced by all >>> PR’s >>>>> that would like no jira. Whoever references that jira will have to >>> think >>>>> twice and might decide it makes more sense to create a specific jira >>>>> instead. >>>> >>>> I don't get the point. If it is only to satisfy a JIRA mandate, we >>>> should really reconsider the mandate. >>>> >>>>> Ilan >>>>> >>>>> On Fri 22 Mar 2024 at 21:57, David Smiley >> wrote: >>>>> >>>>>> There was a recent conversation in priv...@solr.apache.org that >>> should >>>>>> not have been conducted there so I am moving it to the dev list. I >>>>>> intend to hold a VOTE to formalize the decision soon. It would be >> a >>>>>> procedural vote and as-such needs a majority of voters approving >> for >>>>>> it to pass. >>>>>> >>>>>> -- PROPOSAL BEGIN -- >>>>>> JIRA issues are optional for code changes, except non-public >> matters >>>>>> like fixing a security vulnerability. We may have a documented >>>>>> *preference* (e.g. please create them for "big" things but not >>> "small" >>>>>> things), but ultimately it's optional. So if a GitHub PR appears >> to >>>>>> be ready but lacks an associated JIRA -- it may be merged anyway, >>>>>> regardless of documented JIRA usage preferences. >>>>>> -- END -- >>>>>> >>>>>> This isn't the same decision as GitHub Issues vs JIRA -- >>>>>> https://issues.apache.org/jira/browse/SOLR-16455 because this >> isn't >>>>>> about GitHub Issues at all. Nonetheless I think fans of SOLR-16455 >>>>>> would eagerly vote +1 to the proposal here. >>>>>> >>>>>> This doesn't retire Solr's use of JIRA nor make it deprecated. >> JIRA >>>>>> is required for private/security issues that can't be disclosed. >>>>>> >>>>>> Not requiring JIRA does not substantively change our use of >>>>>> CHANGES.txt. Use "PR#2320" syntax, for example (that's an excerpt >> I >>>>>> copy-pasted). PRs don't necessarily need a CHANGES.txt either >> (minor >>>>>> stuff might omit). No change in policy/guidance. >>>>>> >>>>>> Commit messages thus won't have a SOLR- prefix. There is no >>>>>> guidance on what the prefix should be. Please don't use "NO-JIRA". >>>>>> GitHub adds a suffix like (#2320), which is fine; easily click-able >>> in >>>>>> an IDE & GitHub UI. Separately from this discussion thread, I hope >>> we >>>>>> might discuss a useful prefix standard. >>>>>> >>>>>> I acknowledge that optionality in use of JIRA will styme people's >>>>>> attempts to use JIRA as a comprehensive resource of Solr work >>>>>> tracking. For example if you have a JIRA filter / alert on >> keywords >>>>>> of interest; it will become less effective; try switching to emails >>> on >>>>>> the iss...@solr.apache.org list instead. >>>>>> >>>>>> ~ David Smiley >>>>>> Apache Lucene/Solr Search Developer >>>>>> http://www.linkedin.com/in/davidwsmiley >>>>>> >>>>>> >> - >>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>>> >>>>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>> >>>> >>> >>> -- >>> http://www.needhamsoftware.com (work) >>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >>> >> > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Would like some eyes from folks who use zkcli.sh!
The migration of the commands from zkcli.sh over to the bin/solr zk subcommands structure is ready for review. https://github.com/apache/solr/pull/2298 The plan is to keep zkcli.sh on 9x, and remove it in 10. I’m also going to migrate the ./server/scripts/cloud-scripts/snapshotcli.sh over to bin/solr. Once that is done, we can actually eliminate the entire /scripts directory from what we distribute! I’d love to get this merged early next week. Eric ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: [DISCUSS] Community Virtual Meetup, March 2024
Sounds good…. BTW, I’d like to make a plug for C/C NA, apparently the CfP is wrapping soon! > On Mar 21, 2024, at 10:49 PM, David Smiley wrote: > > Sounds good; I can probably join then. Thanks for organizing! > > On Thu, Mar 21, 2024 at 11:26 AM Jason Gerlowski > wrote: >> >> Hey all, >> >> Haven't heard any suggestions on scheduling, so maybe we can aim for noon >> ET on Thursday of next week? That gives us a full week between then and >> now. Pending any last minute objections I'll create the Confluence page >> and Google Meet link later today. >> >> Hope to see many of you there! >> >> Jason >> >> On Tue, Mar 19, 2024 at 8:34 AM Jason Gerlowski >> wrote: >> >>> Hey all, >>> >>> It's time once again to start thinking ahead to our Virtual Meetup for >>> March! (Apologies for starting this discussion a bit late this month, as >>> I've been afk for a few weeks.) >>> >>> Since we are pretty far into the month I'll volunteer to organize the >>> meeting for March, so all we need to do is pick a day and time to meet. >>> Does anyone have opinions on that? Maybe one day next week would make for >>> a good target? >>> >>> Best, >>> >>> Jason >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: MixedCase or dashed-case for long options in Solr CLI?
Thanks for chiming in. Yes, this would be 10 only change. Have you been able to try out the Windows scripts? > On Mar 17, 2024, at 3:05 PM, Shawn Heisey wrote: > > On 3/17/2024 13:01, Shawn Heisey wrote: >> I like there to be a single character option and a kebab-case option. So -z >> and --zk-host. Long options like find uses, such as -name, can be OK, but >> if you're going for standardization, I would just stick with the first two. > > In cases where there might be a conflict for the single-character option, I > would opt to use the single character option for the one that is likely to be > more commonly used. For others, I would choose another single character that > makes some kind of sense, or in some cases, simply opt to not have a single > character option. > > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Compressing state.json being used in ZkCLI.java?
I wanted to follow up and share that I was able to get the compression logic to all work. See https://github.com/apache/solr/pull/2298/commits/ee8657438799c07baadd8efa0f272bb57380d772 I *believe* that we could make the compression logic a option on SolrZkClient.Builder(), maybe SolrZkClient.Builder().withStateFileCompression(minStateByteLenForCompression, compressor) And that would simplify the code…? > On Mar 14, 2024, at 2:44 PM, Eric Pugh > wrote: > > Justin, I went back and crawled through with fresh eyes based on what you > shared ;-). Now I understand that SOLRHOME variable in ZkCLI. > > Okay, so…. It appears that the logic to know if compression is enabled > REQUIRES you to have a solr_home, which means the compressed put only works > if you are on the same box as the solr_home? > > Unless, can I get it from ZK? So that we don’t have to be on the same box? > What if we assume that this property is defined in solr.xml in ZK, and just > look there? Oh wait, Ref Guide says: > > Loading solr.xml from Zookeeper is deprecated, and will not be supported in a > future version. Being the node config of Solr, this file must be available at > early startup and also be allowed to differ between nodes. > > Do we have an API that provides access to Solr’s solr.xml settings? > > I *think* this is hard to solve cleanly because the zk sub commands don’t > interact with Solr, instead they go directly to ZooKeeper.. If they were > mediated by Solr, then the logic about compression choices could remain > purely on the server side and not touch the client…. > > > Eric > > >> On Mar 5, 2024, at 9:39 AM, Eric Pugh >> wrote: >> >> Thanks for sharing this….. >> >> So, maybe the least bad is to just copy the logic, maybe into SolrCLI.java? >> >> >>> On Mar 5, 2024, at 9:29 AM, Justin Sweeney >>> wrote: >>> >>> The tricky part of setData as compared to getData is that in getData we can >>> tell the data is compressed based on the initial bytes read. For setData >>> the only way to know if we should compress the provided data is if we read >>> the solr.xml to know if compression is enabled or by adding an argument to >>> classes like ZkCpTool. >>> >>> Putting an uncompressed state.json into a cluster where compression is used >>> should still work fine so at this point I've erred on people using these >>> tools outside of the Solr cluster having an understanding of how they have >>> set up compression or not for when adding data into the cluster. Not >>> opposed to adding more arguments for some classes, but we don't have a way >>> to just handle compression in setData in the same way we do with getData. >>> >>> On Sat, Mar 2, 2024 at 11:23 AM Eric Pugh >> <mailto:ep...@opensourceconnections.com>> >>> wrote: >>> >>>> Looking at this, when we use the ZkCpTool to upload content, I’m not sure >>>> it goes through the compression step? >>>> >>>> Looks like eventually we get to SolrZkClient.setData() and I don’t see >>>> anything about compression..Unlike the SolrZkClient.getData()… >>>> >>>> Am I reading this right? Shouldn’t setData mimic getData in handling >>>> compression? >>>> >>>> Thanks for looking at this! >>>> >>>> >>>> >>>>> On Feb 29, 2024, at 12:29 PM, Justin Sweeney >>>> wrote: >>>>> >>>>> I actually think that use case should just work since the SolrZkClient >>>> can >>>>> already handle compressed state.json, assuming you are just using the >>>>> default ZLib implementation of compression. When getting data it looks >>>> like >>>>> the ZkCpTool calls SolrZkClient.getData() which is able to check if the >>>>> data is compressed. >>>>> >>>>> On Thu, Feb 29, 2024 at 8:58 AM Eric Pugh < >>>> ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com> >>>> <mailto:ep...@opensourceconnections.com>> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I am poking around ZkCLI.java, and noticed that the compression for a >>>>>> “state.json” file logic is in this file. I’m realizing that the >>>> existing >>>>>> bin/solr zk cp command knows nothing about a “state.json” file being >>>>>> compressed or n
Re: Compressing state.json being used in ZkCLI.java?
Justin, I went back and crawled through with fresh eyes based on what you shared ;-). Now I understand that SOLRHOME variable in ZkCLI. Okay, so…. It appears that the logic to know if compression is enabled REQUIRES you to have a solr_home, which means the compressed put only works if you are on the same box as the solr_home? Unless, can I get it from ZK? So that we don’t have to be on the same box? What if we assume that this property is defined in solr.xml in ZK, and just look there? Oh wait, Ref Guide says: Loading solr.xml from Zookeeper is deprecated, and will not be supported in a future version. Being the node config of Solr, this file must be available at early startup and also be allowed to differ between nodes. Do we have an API that provides access to Solr’s solr.xml settings? I *think* this is hard to solve cleanly because the zk sub commands don’t interact with Solr, instead they go directly to ZooKeeper.. If they were mediated by Solr, then the logic about compression choices could remain purely on the server side and not touch the client…. Eric > On Mar 5, 2024, at 9:39 AM, Eric Pugh wrote: > > Thanks for sharing this….. > > So, maybe the least bad is to just copy the logic, maybe into SolrCLI.java? > >> On Mar 5, 2024, at 9:29 AM, Justin Sweeney >> wrote: >> >> The tricky part of setData as compared to getData is that in getData we can >> tell the data is compressed based on the initial bytes read. For setData >> the only way to know if we should compress the provided data is if we read >> the solr.xml to know if compression is enabled or by adding an argument to >> classes like ZkCpTool. >> >> Putting an uncompressed state.json into a cluster where compression is used >> should still work fine so at this point I've erred on people using these >> tools outside of the Solr cluster having an understanding of how they have >> set up compression or not for when adding data into the cluster. Not >> opposed to adding more arguments for some classes, but we don't have a way >> to just handle compression in setData in the same way we do with getData. >> >> On Sat, Mar 2, 2024 at 11:23 AM Eric Pugh > <mailto:ep...@opensourceconnections.com>> >> wrote: >> >>> Looking at this, when we use the ZkCpTool to upload content, I’m not sure >>> it goes through the compression step? >>> >>> Looks like eventually we get to SolrZkClient.setData() and I don’t see >>> anything about compression..Unlike the SolrZkClient.getData()… >>> >>> Am I reading this right? Shouldn’t setData mimic getData in handling >>> compression? >>> >>> Thanks for looking at this! >>> >>> >>> >>>> On Feb 29, 2024, at 12:29 PM, Justin Sweeney >>> wrote: >>>> >>>> I actually think that use case should just work since the SolrZkClient >>> can >>>> already handle compressed state.json, assuming you are just using the >>>> default ZLib implementation of compression. When getting data it looks >>> like >>>> the ZkCpTool calls SolrZkClient.getData() which is able to check if the >>>> data is compressed. >>>> >>>> On Thu, Feb 29, 2024 at 8:58 AM Eric Pugh < >>> ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com> >>> <mailto:ep...@opensourceconnections.com>> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am poking around ZkCLI.java, and noticed that the compression for a >>>>> “state.json” file logic is in this file. I’m realizing that the >>> existing >>>>> bin/solr zk cp command knows nothing about a “state.json” file being >>>>> compressed or not, and so if you do >>>>> >>>>> bin/solr zk cp my_local_state.json zk:/state.json -z >>> localhost:9983 >>>>> >>>>> Then I think you don’t get the compression aspect kicking in. >>>>> >>>>> I could copy that logic into the ZkCpTool.java, but wondering if there >>> is >>>>> a better refactoring? Could this logic live in either >>> SolrZkClient.java >>>>> or ZkMaintenanceUtils.java ? >>>>> >>>>> Thoughts? >>>>> >>>>> Eric >>>>> ___ >>>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | >>>>> http://www.opensourceconnections.com >>>>> <http://www.
Another set of eyes on SOLR-16824: Adopt Linux Command line tool pattern of -- for long option commands
Hi all…. Jan gave some good feedback on https://github.com/apache/solr/pull/1768…. The tests all pass. I’d love another set of eyes, especially on the Windows side… This is targeted for Solr 10 only. I’d like to get this merged in the next few days. Eric ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Compressing state.json being used in ZkCLI.java?
Thanks for sharing this….. So, maybe the least bad is to just copy the logic, maybe into SolrCLI.java? > On Mar 5, 2024, at 9:29 AM, Justin Sweeney wrote: > > The tricky part of setData as compared to getData is that in getData we can > tell the data is compressed based on the initial bytes read. For setData > the only way to know if we should compress the provided data is if we read > the solr.xml to know if compression is enabled or by adding an argument to > classes like ZkCpTool. > > Putting an uncompressed state.json into a cluster where compression is used > should still work fine so at this point I've erred on people using these > tools outside of the Solr cluster having an understanding of how they have > set up compression or not for when adding data into the cluster. Not > opposed to adding more arguments for some classes, but we don't have a way > to just handle compression in setData in the same way we do with getData. > > On Sat, Mar 2, 2024 at 11:23 AM Eric Pugh <mailto:ep...@opensourceconnections.com>> > wrote: > >> Looking at this, when we use the ZkCpTool to upload content, I’m not sure >> it goes through the compression step? >> >> Looks like eventually we get to SolrZkClient.setData() and I don’t see >> anything about compression..Unlike the SolrZkClient.getData()… >> >> Am I reading this right? Shouldn’t setData mimic getData in handling >> compression? >> >> Thanks for looking at this! >> >> >> >>> On Feb 29, 2024, at 12:29 PM, Justin Sweeney >> wrote: >>> >>> I actually think that use case should just work since the SolrZkClient >> can >>> already handle compressed state.json, assuming you are just using the >>> default ZLib implementation of compression. When getting data it looks >> like >>> the ZkCpTool calls SolrZkClient.getData() which is able to check if the >>> data is compressed. >>> >>> On Thu, Feb 29, 2024 at 8:58 AM Eric Pugh < >> ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com> >> <mailto:ep...@opensourceconnections.com>> >>> wrote: >>> >>>> Hi all, >>>> >>>> I am poking around ZkCLI.java, and noticed that the compression for a >>>> “state.json” file logic is in this file. I’m realizing that the >> existing >>>> bin/solr zk cp command knows nothing about a “state.json” file being >>>> compressed or not, and so if you do >>>> >>>> bin/solr zk cp my_local_state.json zk:/state.json -z >> localhost:9983 >>>> >>>> Then I think you don’t get the compression aspect kicking in. >>>> >>>> I could copy that logic into the ZkCpTool.java, but wondering if there >> is >>>> a better refactoring? Could this logic live in either >> SolrZkClient.java >>>> or ZkMaintenanceUtils.java ? >>>> >>>> Thoughts? >>>> >>>> Eric >>>> ___ >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | >>>> http://www.opensourceconnections.com >>>> <http://www.opensourceconnections.com/> < >>>> http://www.opensourceconnections.com/> | My Free/Busy < >>>> http://tinyurl.com/eric-cal> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >>>> >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw >>> >>>> >>>> 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 <http://www.opensourceconnections.com/> >> < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >> 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 <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: MixedCase or dashed-case for long options in Solr CLI?
-z and --zk-host works for me.
> On Mar 4, 2024, at 9:15 AM, Arrieta, Alejandro
> wrote:
>
> I prefer
>
> —zk-host
>
> Kind Regards,
> Alejandro Arrieta
>
> On Mon, Mar 4, 2024 at 8:45 AM Eric Pugh <mailto:ep...@opensourceconnections.com>>
> wrote:
>
>> “zkHost” —> “—zk-host” or “—zkhost” ?
>>
>>
>>> On Mar 4, 2024, at 6:34 AM, Eric Pugh
>> wrote:
>>>
>>> Kebab! I love it.
>>>
>>>
>>>> On Mar 3, 2024, at 1:14 PM, Arrieta, Alejandro <
>> aarri...@perrinsoftware.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> dashed-case is called kebab case almost everywhere. One example:
>>>> https://www.theserverside.com/definition/Kebab-case
>>>> I was looking at the meaning of dashed-case, and it always pointed to
>>>> kebab-case.
>>>>
>>>> Having kebab, Kamel, and other cases helps troubleshoot over a
>> conference
>>>> to see command errors faster or to tell where to insert other words.
>>>> For scripts it does not matter imho.
>>>>
>>>> Yes, please go with Kebab case everything. Now you know the most common
>>>> name it will never go away.
>>>>
>>>> Kind Regards,
>>>> Alejandro Arrieta
>>>>
>>>> On Sun, Mar 3, 2024 at 2:10 PM Eric Pugh <
>> ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com>
>> <mailto:ep...@opensourceconnections.com>>
>>>> wrote:
>>>>
>>>>> Thanks all for weighing in. So I’m going to go for —dashed-case for
>> long
>>>>> options. So expect some —solr-url and —zk-host parameters coming!
>>>>>
>>>>>
>>>>>
>>>>>> On Feb 26, 2024, at 10:28 AM, Walter Underwood >>>>> <mailto:wun...@wunderwood.org>
>>>
>>>>> wrote:
>>>>>>
>>>>>> Long options are dashed-case, following the GNU convention. POSIX only
>>>>> specifies single character options. The “—“ prefix for long options is
>> a
>>>>> GNU invention, as far as I know. Older Unix commands with long option
>>>>> names, e.g. find, only use a single dash.
>>>>>>
>>>>>>
>> https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html
>>>>>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>>>>>>
>>>>>> wunder
>>>>>> Walter Underwood
>>>>>> wun...@wunderwood.org <mailto:wun...@wunderwood.org>
>>>>>> <mailto:wun...@wunderwood.org> > wun...@wunderwood.org <mailto:wun...@wunderwood.org>>
>>>>>> http://observer.wunderwood.org/ (my blog)
>>>>>>
>>>>>>> On Feb 26, 2024, at 5:29 AM, Eric Pugh <
>> ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com>
>> <mailto:ep...@opensourceconnections.com>
>>>>> <mailto:ep...@opensourceconnections.com>> wrote:
>>>>>>>
>>>>>>> I hear a vote for dashed-case, how about some more votes?
>>>>> —solr-update-url versus —solrUpdateUrl ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Feb 26, 2024, at 7:29 AM, Jason Gerlowski >>>>>>> <mailto:gerlowsk...@gmail.com>
>> <mailto:gerlowsk...@gmail.com>>
>>>>> wrote:
>>>>>>>>
>>>>>>>> My guess is that "dashed-case" is slightly more common -- at least,
>>>>>>>> that's my sense from haphazardly checking a few tools I use often
>>>>>>>> ("curl", "kubectl", "git", "docker").
>>>>>>>>
>>>>>>>> But I don't have an opinion as long as we're internally consistent
>>>>>>>> about using one convention or the other.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Jason
>>>>>>>>
>>>>>>>> On Sat, Feb 24, 2024 at 11:35 AM Eric Pugh
>>>>>>>> >>>>>>> <mailto:ep...@opensourceconnections.com> > ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com
Re: MixedCase or dashed-case for long options in Solr CLI?
“zkHost” —> “—zk-host” or “—zkhost” ?
> On Mar 4, 2024, at 6:34 AM, Eric Pugh wrote:
>
> Kebab! I love it.
>
>
>> On Mar 3, 2024, at 1:14 PM, Arrieta, Alejandro
>> wrote:
>>
>> Hello,
>>
>> dashed-case is called kebab case almost everywhere. One example:
>> https://www.theserverside.com/definition/Kebab-case
>> I was looking at the meaning of dashed-case, and it always pointed to
>> kebab-case.
>>
>> Having kebab, Kamel, and other cases helps troubleshoot over a conference
>> to see command errors faster or to tell where to insert other words.
>> For scripts it does not matter imho.
>>
>> Yes, please go with Kebab case everything. Now you know the most common
>> name it will never go away.
>>
>> Kind Regards,
>> Alejandro Arrieta
>>
>> On Sun, Mar 3, 2024 at 2:10 PM Eric Pugh > <mailto:ep...@opensourceconnections.com>>
>> wrote:
>>
>>> Thanks all for weighing in. So I’m going to go for —dashed-case for long
>>> options. So expect some —solr-url and —zk-host parameters coming!
>>>
>>>
>>>
>>>> On Feb 26, 2024, at 10:28 AM, Walter Underwood
>>> wrote:
>>>>
>>>> Long options are dashed-case, following the GNU convention. POSIX only
>>> specifies single character options. The “—“ prefix for long options is a
>>> GNU invention, as far as I know. Older Unix commands with long option
>>> names, e.g. find, only use a single dash.
>>>>
>>>> https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html
>>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>>>>
>>>> wunder
>>>> Walter Underwood
>>>> wun...@wunderwood.org <mailto:wun...@wunderwood.org>
>>>> <mailto:wun...@wunderwood.org>
>>>> http://observer.wunderwood.org/ (my blog)
>>>>
>>>>> On Feb 26, 2024, at 5:29 AM, Eric Pugh >>>> <mailto:ep...@opensourceconnections.com>
>>> <mailto:ep...@opensourceconnections.com>> wrote:
>>>>>
>>>>> I hear a vote for dashed-case, how about some more votes?
>>> —solr-update-url versus —solrUpdateUrl ?
>>>>>
>>>>>
>>>>>
>>>>>> On Feb 26, 2024, at 7:29 AM, Jason Gerlowski >>>>> <mailto:gerlowsk...@gmail.com>>
>>> wrote:
>>>>>>
>>>>>> My guess is that "dashed-case" is slightly more common -- at least,
>>>>>> that's my sense from haphazardly checking a few tools I use often
>>>>>> ("curl", "kubectl", "git", "docker").
>>>>>>
>>>>>> But I don't have an opinion as long as we're internally consistent
>>>>>> about using one convention or the other.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> On Sat, Feb 24, 2024 at 11:35 AM Eric Pugh
>>>>>> >>>>> <mailto:ep...@opensourceconnections.com> >> ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com>>
>>> <mailto:ep...@opensourceconnections.com>>
>>> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I wanted to get the communities input on formatting of long options
>>> for the Solr CLI. I noticed on
>>> https://commons.apache.org/proper/commons-cli/ that their examples all
>>> are —dashed-case.
>>>>>>>
>>>>>>> However, we have —solrUrl or —zkHost as our pattern. Though in
>>> working on the PostTool, I used —solr-update-url as the parameter because I
>>> had been reading the commons-cli docs...
>>>>>>>
>>>>>>> I’d like to get this sorted so that I can get
>>> https://issues.apache.org/jira/browse/SOLR-16824 over the finish line.
>>> So please do speak up with preferences! (And please let’s not support
>>> both!)
>>>>>>>
>>>>>>>
>>>>>>> The changes to the formatting will be a 10x thing.
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>> ___
>>>>>>> Eric Pugh | Founder & CEO | OpenSource Connections,
Re: MixedCase or dashed-case for long options in Solr CLI?
Kebab! I love it.
> On Mar 3, 2024, at 1:14 PM, Arrieta, Alejandro
> wrote:
>
> Hello,
>
> dashed-case is called kebab case almost everywhere. One example:
> https://www.theserverside.com/definition/Kebab-case
> I was looking at the meaning of dashed-case, and it always pointed to
> kebab-case.
>
> Having kebab, Kamel, and other cases helps troubleshoot over a conference
> to see command errors faster or to tell where to insert other words.
> For scripts it does not matter imho.
>
> Yes, please go with Kebab case everything. Now you know the most common
> name it will never go away.
>
> Kind Regards,
> Alejandro Arrieta
>
> On Sun, Mar 3, 2024 at 2:10 PM Eric Pugh <mailto:ep...@opensourceconnections.com>>
> wrote:
>
>> Thanks all for weighing in. So I’m going to go for —dashed-case for long
>> options. So expect some —solr-url and —zk-host parameters coming!
>>
>>
>>
>>> On Feb 26, 2024, at 10:28 AM, Walter Underwood
>> wrote:
>>>
>>> Long options are dashed-case, following the GNU convention. POSIX only
>> specifies single character options. The “—“ prefix for long options is a
>> GNU invention, as far as I know. Older Unix commands with long option
>> names, e.g. find, only use a single dash.
>>>
>>> https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html
>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>>>
>>> wunder
>>> Walter Underwood
>>> wun...@wunderwood.org <mailto:wun...@wunderwood.org>
>>> <mailto:wun...@wunderwood.org>
>>> http://observer.wunderwood.org/ (my blog)
>>>
>>>> On Feb 26, 2024, at 5:29 AM, Eric Pugh >>> <mailto:ep...@opensourceconnections.com>
>> <mailto:ep...@opensourceconnections.com>> wrote:
>>>>
>>>> I hear a vote for dashed-case, how about some more votes?
>> —solr-update-url versus —solrUpdateUrl ?
>>>>
>>>>
>>>>
>>>>> On Feb 26, 2024, at 7:29 AM, Jason Gerlowski >>>> <mailto:gerlowsk...@gmail.com>>
>> wrote:
>>>>>
>>>>> My guess is that "dashed-case" is slightly more common -- at least,
>>>>> that's my sense from haphazardly checking a few tools I use often
>>>>> ("curl", "kubectl", "git", "docker").
>>>>>
>>>>> But I don't have an opinion as long as we're internally consistent
>>>>> about using one convention or the other.
>>>>>
>>>>> Best,
>>>>>
>>>>> Jason
>>>>>
>>>>> On Sat, Feb 24, 2024 at 11:35 AM Eric Pugh
>>>>> mailto:ep...@opensourceconnections.com>
>>>>> > ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com>>
>> <mailto:ep...@opensourceconnections.com>>
>> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I wanted to get the communities input on formatting of long options
>> for the Solr CLI. I noticed on
>> https://commons.apache.org/proper/commons-cli/ that their examples all
>> are —dashed-case.
>>>>>>
>>>>>> However, we have —solrUrl or —zkHost as our pattern. Though in
>> working on the PostTool, I used —solr-update-url as the parameter because I
>> had been reading the commons-cli docs...
>>>>>>
>>>>>> I’d like to get this sorted so that I can get
>> https://issues.apache.org/jira/browse/SOLR-16824 over the finish line.
>> So please do speak up with preferences! (And please let’s not support
>> both!)
>>>>>>
>>>>>>
>>>>>> The changes to the formatting will be a 10x thing.
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>> ___
>>>>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC |
>> 434.466.1467 | http://www.opensourceconnections.com
>> <http://www.opensourceconnections.com/> <
>> http://www.opensourceconnections.com/> <
>> http://www.opensourceconnections.com/><
>> http://www.opensourceconnections.com/> | My Free/Busy <
>> http://tinyurl.com/eric-cal>
>>>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
>> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-searc
Re: MixedCase or dashed-case for long options in Solr CLI?
Thanks all for weighing in. So I’m going to go for —dashed-case for long
options. So expect some —solr-url and —zk-host parameters coming!
> On Feb 26, 2024, at 10:28 AM, Walter Underwood wrote:
>
> Long options are dashed-case, following the GNU convention. POSIX only
> specifies single character options. The “—“ prefix for long options is a GNU
> invention, as far as I know. Older Unix commands with long option names, e.g.
> find, only use a single dash.
>
> https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>
> wunder
> Walter Underwood
> wun...@wunderwood.org <mailto:wun...@wunderwood.org>
> http://observer.wunderwood.org/ (my blog)
>
>> On Feb 26, 2024, at 5:29 AM, Eric Pugh > <mailto:ep...@opensourceconnections.com>> wrote:
>>
>> I hear a vote for dashed-case, how about some more votes? —solr-update-url
>> versus —solrUpdateUrl ?
>>
>>
>>
>>> On Feb 26, 2024, at 7:29 AM, Jason Gerlowski wrote:
>>>
>>> My guess is that "dashed-case" is slightly more common -- at least,
>>> that's my sense from haphazardly checking a few tools I use often
>>> ("curl", "kubectl", "git", "docker").
>>>
>>> But I don't have an opinion as long as we're internally consistent
>>> about using one convention or the other.
>>>
>>> Best,
>>>
>>> Jason
>>>
>>> On Sat, Feb 24, 2024 at 11:35 AM Eric Pugh
>>> mailto:ep...@opensourceconnections.com>
>>> <mailto:ep...@opensourceconnections.com>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I wanted to get the communities input on formatting of long options for
>>>> the Solr CLI. I noticed on
>>>> https://commons.apache.org/proper/commons-cli/ that their examples all are
>>>> —dashed-case.
>>>>
>>>> However, we have —solrUrl or —zkHost as our pattern. Though in working
>>>> on the PostTool, I used —solr-update-url as the parameter because I had
>>>> been reading the commons-cli docs...
>>>>
>>>> I’d like to get this sorted so that I can get
>>>> https://issues.apache.org/jira/browse/SOLR-16824 over the finish line.
>>>> So please do speak up with preferences! (And please let’s not support
>>>> both!)
>>>>
>>>>
>>>> The changes to the formatting will be a 10x thing.
>>>>
>>>> Eric
>>>>
>>>> ___
>>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
>>>> http://www.opensourceconnections.com
>>>> <http://www.opensourceconnections.com/>
>>>> <http://www.opensourceconnections.com/><http://www.opensourceconnections.com/>
>>>> | My Free/Busy <http://tinyurl.com/eric-cal>
>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>>>> 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
>>> <mailto:dev-unsubscr...@solr.apache.org>
>>> <mailto:dev-unsubscr...@solr.apache.org>
>>> For additional commands, e-mail: dev-h...@solr.apache.org
>>> <mailto:dev-h...@solr.apache.org> <mailto:dev-h...@solr.apache.org>
>> ___
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
>> http://www.opensourceconnections.com <http://www.opensourceconnections.com/>
>> <http://www.opensourceconnections.com/> | My Free/Busy
>> <http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>>
>> 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 <http://www.opensourceconnections.com/> |
My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
<https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
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.
Re: Compressing state.json being used in ZkCLI.java?
Looking at this, when we use the ZkCpTool to upload content, I’m not sure it goes through the compression step? Looks like eventually we get to SolrZkClient.setData() and I don’t see anything about compression..Unlike the SolrZkClient.getData()… Am I reading this right? Shouldn’t setData mimic getData in handling compression? Thanks for looking at this! > On Feb 29, 2024, at 12:29 PM, Justin Sweeney > wrote: > > I actually think that use case should just work since the SolrZkClient can > already handle compressed state.json, assuming you are just using the > default ZLib implementation of compression. When getting data it looks like > the ZkCpTool calls SolrZkClient.getData() which is able to check if the > data is compressed. > > On Thu, Feb 29, 2024 at 8:58 AM Eric Pugh <mailto:ep...@opensourceconnections.com>> > wrote: > >> Hi all, >> >> I am poking around ZkCLI.java, and noticed that the compression for a >> “state.json” file logic is in this file. I’m realizing that the existing >> bin/solr zk cp command knows nothing about a “state.json” file being >> compressed or not, and so if you do >> >>bin/solr zk cp my_local_state.json zk:/state.json -z localhost:9983 >> >> Then I think you don’t get the compression aspect kicking in. >> >> I could copy that logic into the ZkCpTool.java, but wondering if there is >> a better refactoring? Could this logic live in either SolrZkClient.java >> or ZkMaintenanceUtils.java ? >> >> Thoughts? >> >> Eric >> ___ >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >> 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 <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Compressing state.json being used in ZkCLI.java?
Hi all, I am poking around ZkCLI.java, and noticed that the compression for a “state.json” file logic is in this file. I’m realizing that the existing bin/solr zk cp command knows nothing about a “state.json” file being compressed or not, and so if you do bin/solr zk cp my_local_state.json zk:/state.json -z localhost:9983 Then I think you don’t get the compression aspect kicking in. I could copy that logic into the ZkCpTool.java, but wondering if there is a better refactoring? Could this logic live in either SolrZkClient.java or ZkMaintenanceUtils.java ? Thoughts? Eric ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Moving to bin/solr start defaulting to SolrCloud mode?
This change is definitely NOT about requiring them to use Solr Cloud…. We’ve changed the bin/solr script to require a “start” parameter, so “bin/solr start” to fire up solr, so if you are used to "bin/solr", you will need to learn the “bin/solr start” command. Though, if you are using install scripts, that probably doesn’t matter. For those who don’t want Solr Cloud, you just need to add a flag, so “bin solr start -standalone” for example... > On Feb 28, 2024, at 12:55 PM, Uwe Schindler wrote: > > Please no :-) 100% of my small/medium sized customers would never ever use > Solr Cloud. > > Uwe > > Am 23.02.2024 um 19:06 schrieb Eric Pugh: >> During today’s community discussion the topic of moving to defaulting to >> SolrCloud mode came up. >> >> The idea here is that when a user run’s “bin/solr start” it fires up an >> embedded zookeeper. Same behavior as “bin/solr -c” in Solr 9.5.If you >> have a Zookeeper Ensemble then “bin/solr start -z YOUR_ZK_SETUP” would >> connect to the external ensemble instead. >> >> If you want to continue to use the class user managed mode, then bin/solr >> start —user-managed maybe? Or bin/solr start —standalone ??? >> >> Other changes would be to go through the Ref Guide and where we have both >> SolrCloud and non SolrCloud content that we make sure SolrCloud content is >> at the top instead of at the bottom. >> >> To me, this feels like a change that would go on main. >> >> Thoughts? >> >> Eric >> >> >> >> >> >> >> >> >> ___ >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com >> <http://www.opensourceconnections.com/><http://www.opensourceconnections.com/> >> | My Free/Busy <http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed >> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >> 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. >> >> > -- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de <https://www.thetaphi.de/> > eMail: u...@thetaphi.de <mailto:u...@thetaphi.de> > > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > <mailto:dev-unsubscr...@solr.apache.org> > For additional commands, e-mail: dev-h...@solr.apache.org > <mailto:dev-h...@solr.apache.org> ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Moving to bin/solr start defaulting to SolrCloud mode?
Thanks for the link…. I don’t think anything I read in the thread suggested that merely changing the default to cloud mode instead of standalone mode (sounds like we are going back to that term!) would raise any issues. Obviously deprecating standalone is a much bigger deal and not part of the scope of this thread…. > On Feb 26, 2024, at 7:35 PM, David Smiley wrote: > > Whoops; bad URL. Here it is: > https://lists.apache.org/thread/r7mh069t5zvqv3o3ymglm627pcdgjzfw > > On Mon, Feb 26, 2024 at 3:59 PM David Smiley wrote: >> >> Also reference a bigger discussion of August that same year: >> "SolrCloud Alone: Deprecate Standalone Mode" >> https://lists.apache.org/list.html?dev@solr.apache.org >> >> (reading past conversations on a topic should be required reading when >> introducing again) >> >> RE "user-managed" I recall Cassandra was working on the ref guide and >> tried to get us to harmonize on some terminology. Ultimately "user >> managed" was chosen and thus this term is widespread in the ref guide >> despite "standalone" clearly being used for many years. Personally, I >> *much* prefer "standalone" and continue to use it (sorry?). >> >> On Fri, Feb 23, 2024 at 7:14 PM Jan Høydahl wrote: >>> >>> Cross referencing earlier discussion "[DISCUSS] Make Cloud mode the default >>> option in bin/solr" from May 2021: >>> https://lists.apache.org/thread/79xp2xfvqwhr9zccmsvjvj0hckgg5m6w >>> >>> Some valid arguments for an against in that thread. >>> >>> Ideally I'd prefer SIP-14 to be done before embedded zk is promoted as the >>> best way to run Solr. >>> >>> Jan >>> >>>> 23. feb. 2024 kl. 19:06 skrev Eric Pugh : >>>> >>>> During today’s community discussion the topic of moving to defaulting to >>>> SolrCloud mode came up. >>>> >>>> The idea here is that when a user run’s “bin/solr start” it fires up an >>>> embedded zookeeper. Same behavior as “bin/solr -c” in Solr 9.5.If >>>> you have a Zookeeper Ensemble then “bin/solr start -z YOUR_ZK_SETUP” would >>>> connect to the external ensemble instead. >>>> >>>> If you want to continue to use the class user managed mode, then bin/solr >>>> start —user-managed maybe? Or bin/solr start —standalone ??? >>>> >>>> Other changes would be to go through the Ref Guide and where we have both >>>> SolrCloud and non SolrCloud content that we make sure SolrCloud content is >>>> at the top instead of at the bottom. >>>> >>>> To me, this feels like a change that would go on main. >>>> >>>> Thoughts? >>>> >>>> Eric >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ___ >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | >>>> http://www.opensourceconnections.com >>>> <http://www.opensourceconnections.com/> | My Free/Busy >>>> <http://tinyurl.com/eric-cal> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed >>>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >>>> 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 > ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Moving to bin/solr start defaulting to SolrCloud mode?
Can you re-share that link to the thread "SolrCloud Alone: Deprecate Standalone Mode”. I took a look and didn’t find it. We could change to standalone ;-). We have a nice glossary in our ref guide https://solr.apache.org/guide/solr/latest/getting-started/solr-glossary.html that doesn’t actually include “Standalone” or “User Managed”. > On Feb 26, 2024, at 3:59 PM, David Smiley wrote: > > Also reference a bigger discussion of August that same year: > "SolrCloud Alone: Deprecate Standalone Mode" > https://lists.apache.org/list.html?dev@solr.apache.org > > (reading past conversations on a topic should be required reading when > introducing again) > > RE "user-managed" I recall Cassandra was working on the ref guide and > tried to get us to harmonize on some terminology. Ultimately "user > managed" was chosen and thus this term is widespread in the ref guide > despite "standalone" clearly being used for many years. Personally, I > *much* prefer "standalone" and continue to use it (sorry?). > > On Fri, Feb 23, 2024 at 7:14 PM Jan Høydahl wrote: >> >> Cross referencing earlier discussion "[DISCUSS] Make Cloud mode the default >> option in bin/solr" from May 2021: >> https://lists.apache.org/thread/79xp2xfvqwhr9zccmsvjvj0hckgg5m6w >> >> Some valid arguments for an against in that thread. >> >> Ideally I'd prefer SIP-14 to be done before embedded zk is promoted as the >> best way to run Solr. >> >> Jan >> >>> 23. feb. 2024 kl. 19:06 skrev Eric Pugh : >>> >>> During today’s community discussion the topic of moving to defaulting to >>> SolrCloud mode came up. >>> >>> The idea here is that when a user run’s “bin/solr start” it fires up an >>> embedded zookeeper. Same behavior as “bin/solr -c” in Solr 9.5.If you >>> have a Zookeeper Ensemble then “bin/solr start -z YOUR_ZK_SETUP” would >>> connect to the external ensemble instead. >>> >>> If you want to continue to use the class user managed mode, then bin/solr >>> start —user-managed maybe? Or bin/solr start —standalone ??? >>> >>> Other changes would be to go through the Ref Guide and where we have both >>> SolrCloud and non SolrCloud content that we make sure SolrCloud content is >>> at the top instead of at the bottom. >>> >>> To me, this feels like a change that would go on main. >>> >>> Thoughts? >>> >>> Eric >>> >>> >>> >>> >>> >>> >>> >>> >>> ___ >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | >>> http://www.opensourceconnections.com >>> <http://www.opensourceconnections.com/> | My Free/Busy >>> <http://tinyurl.com/eric-cal> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed >>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >>> 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 > ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Moving to bin/solr start defaulting to SolrCloud mode?
I’ll inline my responses... > On Feb 26, 2024, at 7:34 AM, Arrieta, Alejandro > wrote: > > Hello Eric, > > 1) The idea here is that when a user run’s “bin/solr start” it fires up an > embedded zookeeper. Same behavior as “bin/solr -c” in Solr 9.5.If you > have a Zookeeper Ensemble then “bin/solr start -z YOUR_ZK_SETUP” would > connect to the external ensemble instead. > If Solrcloud is the new default, this sounds good to me from a user > perspective. This is correct. Jason G and I started looking at how we could handle https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper as part of this. > > 2) bin/solr start —standalone > I have always known the modes as standalone and solrcloud. But current > documentation uses "user-managed" instead of "standalone": > https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-types.html#solrcloud-mode > Mail thread shared by Jan uses "standalone" too. > IMHO, standalone describes it better, but if all users know it as > "user-managed" and documentation uses that name. I have to agree that “standalone” makes more sense to me as well. I think the idea of “user-managed” was to really highlight “hey, you are doing all the management of coordination”…. It feels like a bit of very in the weeds specification that most folks won’t care about. > > 2) Ref Guide changes to put Solrcloud first and standalone/user-managed > second. > Not all docs have solrcloud at the end. Some point to a different page for > solrcloud at the start, like Backups: > https://solr.apache.org/guide/solr/latest/deployment-guide/backup-restore.html > The new/current default should appear first in the documentation, including > the starting guide. I know from my experience users will not read the > complete page and use/test the first part. That’s a great perspective, and I agree. > > Kind Regards, > Alejandro Arrieta > > On Mon, Feb 26, 2024 at 9:23 AM Jason Gerlowski > wrote: > >> Thanks for the link to that 2021 discussion Jan - had forgotten about that. >> >> I agree that SIP-14 (or some portion of it) goes a long way towards >> making SolrCloud (w/ embedded ZK) a more serviceable default. >> >> On Fri, Feb 23, 2024 at 7:14 PM Jan Høydahl wrote: >>> >>> Cross referencing earlier discussion "[DISCUSS] Make Cloud mode the >> default option in bin/solr" from May 2021: >>> https://lists.apache.org/thread/79xp2xfvqwhr9zccmsvjvj0hckgg5m6w >>> >>> Some valid arguments for an against in that thread. >>> >>> Ideally I'd prefer SIP-14 to be done before embedded zk is promoted as >> the best way to run Solr. >>> >>> Jan >>> >>>> 23. feb. 2024 kl. 19:06 skrev Eric Pugh < >> ep...@opensourceconnections.com>: >>>> >>>> During today’s community discussion the topic of moving to defaulting >> to SolrCloud mode came up. >>>> >>>> The idea here is that when a user run’s “bin/solr start” it fires up >> an embedded zookeeper. Same behavior as “bin/solr -c” in Solr 9.5.If >> you have a Zookeeper Ensemble then “bin/solr start -z YOUR_ZK_SETUP” would >> connect to the external ensemble instead. >>>> >>>> If you want to continue to use the class user managed mode, then >> bin/solr start —user-managed maybe? Or bin/solr start —standalone ??? >>>> >>>> Other changes would be to go through the Ref Guide and where we have >> both SolrCloud and non SolrCloud content that we make sure SolrCloud >> content is at the top instead of at the bottom. >>>> >>>> To me, this feels like a change that would go on main. >>>> >>>> Thoughts? >>>> >>>> Eric >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ___ >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 >> | http://www.opensourceconnections.com < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw >>> >>>> 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. >>>> >>
Re: MixedCase or dashed-case for long options in Solr CLI?
I hear a vote for dashed-case, how about some more votes? —solr-update-url
versus —solrUpdateUrl ?
> On Feb 26, 2024, at 7:29 AM, Jason Gerlowski wrote:
>
> My guess is that "dashed-case" is slightly more common -- at least,
> that's my sense from haphazardly checking a few tools I use often
> ("curl", "kubectl", "git", "docker").
>
> But I don't have an opinion as long as we're internally consistent
> about using one convention or the other.
>
> Best,
>
> Jason
>
> On Sat, Feb 24, 2024 at 11:35 AM Eric Pugh
> mailto:ep...@opensourceconnections.com>>
> wrote:
>>
>> Hi all,
>>
>> I wanted to get the communities input on formatting of long options for the
>> Solr CLI. I noticed on https://commons.apache.org/proper/commons-cli/ that
>> their examples all are —dashed-case.
>>
>> However, we have —solrUrl or —zkHost as our pattern. Though in working on
>> the PostTool, I used —solr-update-url as the parameter because I had been
>> reading the commons-cli docs...
>>
>> I’d like to get this sorted so that I can get
>> https://issues.apache.org/jira/browse/SOLR-16824 over the finish line. So
>> please do speak up with preferences! (And please let’s not support both!)
>>
>>
>> The changes to the formatting will be a 10x thing.
>>
>> Eric
>>
>> ___
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
>> http://www.opensourceconnections.com
>> <http://www.opensourceconnections.com/><http://www.opensourceconnections.com/>
>> | My Free/Busy <http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>> 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
> <mailto:dev-unsubscr...@solr.apache.org>
> For additional commands, e-mail: dev-h...@solr.apache.org
> <mailto:dev-h...@solr.apache.org>
___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
http://www.opensourceconnections.com <http://www.opensourceconnections.com/> |
My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
<https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
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.
MixedCase or dashed-case for long options in Solr CLI?
Hi all, I wanted to get the communities input on formatting of long options for the Solr CLI. I noticed on https://commons.apache.org/proper/commons-cli/ that their examples all are —dashed-case. However, we have —solrUrl or —zkHost as our pattern. Though in working on the PostTool, I used —solr-update-url as the parameter because I had been reading the commons-cli docs... I’d like to get this sorted so that I can get https://issues.apache.org/jira/browse/SOLR-16824 over the finish line. So please do speak up with preferences! (And please let’s not support both!) The changes to the formatting will be a 10x thing. Eric ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Moving to bin/solr start defaulting to SolrCloud mode?
During today’s community discussion the topic of moving to defaulting to SolrCloud mode came up. The idea here is that when a user run’s “bin/solr start” it fires up an embedded zookeeper. Same behavior as “bin/solr -c” in Solr 9.5.If you have a Zookeeper Ensemble then “bin/solr start -z YOUR_ZK_SETUP” would connect to the external ensemble instead. If you want to continue to use the class user managed mode, then bin/solr start —user-managed maybe? Or bin/solr start —standalone ??? Other changes would be to go through the Ref Guide and where we have both SolrCloud and non SolrCloud content that we make sure SolrCloud content is at the top instead of at the bottom. To me, this feels like a change that would go on main. Thoughts? Eric ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Fixing the builds...
I think I have (finally) made the PostToolTest.java in main and branch_9x pretty much the same so that back porting goes simpler and less error prone. Sorry Gus for catching you with that! Eric ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: [DISCUSS] Community Virtual Meetup, February 2024
Thanks! > On Feb 17, 2024, at 10:18 AM, Jason Gerlowski wrote: > > Alright - looks like everyone's schedule is pretty flexible, so 2/23 > wins with Bruno's lone vote :-p > > Will share the Confluence, Meetup.com, and Google Meet links shortly; > see you all next week! > > Best, > > Jason > > On Thu, Feb 15, 2024 at 5:42 PM Alessandro Benedetti > wrote: >> >> Thanks for organising this! I am good with all of them! >> Cheers >> -- >> *Alessandro Benedetti* >> Director @ Sease Ltd. >> *Apache Lucene/Solr Committer* >> *Apache Solr PMC Member* >> >> e-mail: a.benede...@sease.io >> >> >> *Sease* - Information Retrieval Applied >> Consulting | Training | Open Source >> >> Website: Sease.io <http://sease.io/> >> LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter >> <https://twitter.com/seaseltd> | Youtube >> <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github >> <https://github.com/seaseltd> >> >> >> On Wed, 14 Feb 2024 at 00:47, Ilan Ginzburg wrote: >> >>> Thanks for organizing this. >>> >>> I vote *not* 2/20 and *not* 2/22. >>> >>> On Tue 13 Feb 2024 at 22:53, Bruno Roustant >>> wrote: >>> >>>> I vote for 2/23 >>>> >>>> Thanks Jason >>>> >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Use cases for interacting direct with ZK versus using our APIs?
Assuming an API existed, would that then be a good way? Or are there times when an API wouldn’t do what direct ZK does? > On Feb 12, 2024, at 9:13 AM, Jason Gerlowski wrote: > >> What other use cases are there for us interacting directly with ZK? > > Reading cluster/replica/collection properties for sure. There are some > Solr APIs to modify these things, but afaik users that want to check the > value of a particular (e.g.) cluster-property don't have a way to do that > yet without reading it out of ZK directly. > > On Sun, Feb 11, 2024 at 1:58 PM Eric Pugh <mailto:ep...@opensourceconnections.com>> > wrote: > >> I like your suggestion David on the CLI supporting configset directly. >> I’m sort of waiting till the V2 api for putting configsets is done. >> According to the Solr v2 API Proposed Changes spreadsheet, while there is a >> V2 api, it hasn’t been given the “restful/jax-rs/exposed in solrj” >> treatment yet…. >> >> I also agree that figuring out how to make ZK an internal detail is >> somewhat underlying my question…. >> >> What other use cases are there for us interacting directly with ZK? >> >>> On Feb 11, 2024, at 12:57 PM, David Smiley wrote: >>> >>> I suppose direct ZK has an advantage of not requiring that Solr is >>> running yet. But maybe that's moot. I do think it would make sense >>> to have CLI options for configset upload that use Solr's API and don't >>> refer to ZK. Broadly, this is the direction we're going in; ZK is >>> more of an internal detail, even though it's obviously a critical >>> thing. >>> >>> On Sun, Feb 11, 2024 at 12:26 PM Eric Pugh >>> mailto:ep...@opensourceconnections.com> >>> <mailto:ep...@opensourceconnections.com>> >> wrote: >>>> >>>> Ah.. yeah, I can’t speak to Solr 6.x! In 9x at least you could use >> the configset API to deploy configs and avoid the direct ZK interaction. >>>> >>>> It would be interesting to explore if the process of deploying a >> configset is risky, has a high chance of things failing, then how do we >> account for that as part of the process?So you don’t have to do things >> like upload the previous config ;-). >>>> >>>> And other common reasons to use ZK directly? >>>> >>>>> On Feb 11, 2024, at 12:14 PM, Walter Underwood >>>> <mailto:wun...@wunderwood.org>> >> wrote: >>>>> >>>>> The was deploying configs with Jenkins on Solr 6.x. Maybe the APIs >> were there, but I didn't know about them. >>>>> >>>>> Rebuilding the suggester did need external help, since that needs to >> be done separately on each node. >>>>> >>>>> I think working directly with Zookeeper is less risky. If there is any >> issue with the upload, then don’t reload the collections. You can back out >> the changes by uploading the previous config to Zookeeper. >>>>> >>>>> wunder >>>>> Walter Underwood >>>>> wun...@wunderwood.org <mailto:wun...@wunderwood.org> >>>>> <mailto:wun...@wunderwood.org> > wun...@wunderwood.org <mailto:wun...@wunderwood.org>> >>>>> http://observer.wunderwood.org/ (my blog) >>>>> >>>>>> On Feb 11, 2024, at 11:07 AM, Eric Pugh < >> ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com> >> <mailto:ep...@opensourceconnections.com> >> <mailto:ep...@opensourceconnections.com>> wrote: >>>>>> >>>>>> Could you share more about “update Solr remotely” that you were >> doing? Are we missing some APIs that would have made whatever you had to >> do require ZK direct access? >>>>>> >>>>>> While it’s cool that we can impact Solr via hacking around in ZK, it >> also seems like an approach fraught with risk! >>>>>> >>>>>>> On Feb 11, 2024, at 11:32 AM, Walter Underwood < >> wun...@wunderwood.org <mailto:wun...@wunderwood.org> >> <mailto:wun...@wunderwood.org>> wrote: >>>>>>> >>>>>>> I wanted something that didn’t require installing Solr locally in >> order to update Solr remotely, so I didn’t use the provided zk commands. I >> wrote some Python to dig the Zookeeper addresses out of clusterstatus (I >> think) then uploaded directly to Zookeeper with the Python kazoo package. >>>>>>>
Re: Use cases for interacting direct with ZK versus using our APIs?
I like your suggestion David on the CLI supporting configset directly. I’m sort of waiting till the V2 api for putting configsets is done. According to the Solr v2 API Proposed Changes spreadsheet, while there is a V2 api, it hasn’t been given the “restful/jax-rs/exposed in solrj” treatment yet…. I also agree that figuring out how to make ZK an internal detail is somewhat underlying my question…. What other use cases are there for us interacting directly with ZK? > On Feb 11, 2024, at 12:57 PM, David Smiley wrote: > > I suppose direct ZK has an advantage of not requiring that Solr is > running yet. But maybe that's moot. I do think it would make sense > to have CLI options for configset upload that use Solr's API and don't > refer to ZK. Broadly, this is the direction we're going in; ZK is > more of an internal detail, even though it's obviously a critical > thing. > > On Sun, Feb 11, 2024 at 12:26 PM Eric Pugh > mailto:ep...@opensourceconnections.com>> > wrote: >> >> Ah.. yeah, I can’t speak to Solr 6.x! In 9x at least you could use the >> configset API to deploy configs and avoid the direct ZK interaction. >> >> It would be interesting to explore if the process of deploying a configset >> is risky, has a high chance of things failing, then how do we account for >> that as part of the process?So you don’t have to do things like upload >> the previous config ;-). >> >> And other common reasons to use ZK directly? >> >>> On Feb 11, 2024, at 12:14 PM, Walter Underwood >>> wrote: >>> >>> The was deploying configs with Jenkins on Solr 6.x. Maybe the APIs were >>> there, but I didn't know about them. >>> >>> Rebuilding the suggester did need external help, since that needs to be >>> done separately on each node. >>> >>> I think working directly with Zookeeper is less risky. If there is any >>> issue with the upload, then don’t reload the collections. You can back out >>> the changes by uploading the previous config to Zookeeper. >>> >>> wunder >>> Walter Underwood >>> wun...@wunderwood.org <mailto:wun...@wunderwood.org> >>> <mailto:wun...@wunderwood.org> >>> http://observer.wunderwood.org/ (my blog) >>> >>>> On Feb 11, 2024, at 11:07 AM, Eric Pugh >>> <mailto:ep...@opensourceconnections.com> >>>> <mailto:ep...@opensourceconnections.com>> wrote: >>>> >>>> Could you share more about “update Solr remotely” that you were doing? >>>> Are we missing some APIs that would have made whatever you had to do >>>> require ZK direct access? >>>> >>>> While it’s cool that we can impact Solr via hacking around in ZK, it also >>>> seems like an approach fraught with risk! >>>> >>>>> On Feb 11, 2024, at 11:32 AM, Walter Underwood >>>> <mailto:wun...@wunderwood.org>> wrote: >>>>> >>>>> I wanted something that didn’t require installing Solr locally in order >>>>> to update Solr remotely, so I didn’t use the provided zk commands. I >>>>> wrote some Python to dig the Zookeeper addresses out of clusterstatus (I >>>>> think) then uploaded directly to Zookeeper with the Python kazoo package. >>>>> >>>>> The tool had a bunch of other things, like async reload checking for >>>>> results, and rebuilding suggestion dictionaries on each node. >>>>> >>>>> wunder >>>>> Walter Underwood >>>>> wun...@wunderwood.org <mailto:wun...@wunderwood.org> >>>>> http://observer.wunderwood.org/ (my blog) >>>>> >>>>>> On Feb 11, 2024, at 9:04 AM, Gus Heck >>>>> <mailto:gus.h...@gmail.com>> wrote: >>>>>> >>>>>> I pretty much always use zk upconfig, which also works for overwriting >>>>>> existing. I certainly tell my clients to use apis from the ref guide for >>>>>> such operations, but zk upconfig certainly counts as one. Mostly I tell >>>>>> them that they should only break out things like >>>>>> https://github.com/rgs1/zk_shell as a last resort (which is what I think >>>>>> of >>>>>> as direct modification), and if they are unsure, call me *before* doing >>>>>> anything in zk directly. >>>>>> >>>>>> By the way, I don't know if this has come up in a dev/build setting or >>&
Re: Use cases for interacting direct with ZK versus using our APIs?
Ah.. yeah, I can’t speak to Solr 6.x! In 9x at least you could use the configset API to deploy configs and avoid the direct ZK interaction. It would be interesting to explore if the process of deploying a configset is risky, has a high chance of things failing, then how do we account for that as part of the process?So you don’t have to do things like upload the previous config ;-). And other common reasons to use ZK directly? > On Feb 11, 2024, at 12:14 PM, Walter Underwood wrote: > > The was deploying configs with Jenkins on Solr 6.x. Maybe the APIs were > there, but I didn't know about them. > > Rebuilding the suggester did need external help, since that needs to be done > separately on each node. > > I think working directly with Zookeeper is less risky. If there is any issue > with the upload, then don’t reload the collections. You can back out the > changes by uploading the previous config to Zookeeper. > > wunder > Walter Underwood > wun...@wunderwood.org <mailto:wun...@wunderwood.org> > http://observer.wunderwood.org/ (my blog) > >> On Feb 11, 2024, at 11:07 AM, Eric Pugh > <mailto:ep...@opensourceconnections.com>> wrote: >> >> Could you share more about “update Solr remotely” that you were doing? Are >> we missing some APIs that would have made whatever you had to do require ZK >> direct access? >> >> While it’s cool that we can impact Solr via hacking around in ZK, it also >> seems like an approach fraught with risk! >> >>> On Feb 11, 2024, at 11:32 AM, Walter Underwood >>> wrote: >>> >>> I wanted something that didn’t require installing Solr locally in order to >>> update Solr remotely, so I didn’t use the provided zk commands. I wrote >>> some Python to dig the Zookeeper addresses out of clusterstatus (I think) >>> then uploaded directly to Zookeeper with the Python kazoo package. >>> >>> The tool had a bunch of other things, like async reload checking for >>> results, and rebuilding suggestion dictionaries on each node. >>> >>> wunder >>> Walter Underwood >>> wun...@wunderwood.org >>> http://observer.wunderwood.org/ (my blog) >>> >>>> On Feb 11, 2024, at 9:04 AM, Gus Heck wrote: >>>> >>>> I pretty much always use zk upconfig, which also works for overwriting >>>> existing. I certainly tell my clients to use apis from the ref guide for >>>> such operations, but zk upconfig certainly counts as one. Mostly I tell >>>> them that they should only break out things like >>>> https://github.com/rgs1/zk_shell as a last resort (which is what I think of >>>> as direct modification), and if they are unsure, call me *before* doing >>>> anything in zk directly. >>>> >>>> By the way, I don't know if this has come up in a dev/build setting or not, >>>> but are you aware of https://plugins.gradle.org/search?term=solr ? It is >>>> presently only really suitable for local dev, with a single config set, but >>>> could easily grow patches and suggestions welcome of course. >>>> >>>> On Sun, Feb 11, 2024, 9:10 AM Eric Pugh >>>> wrote: >>>> >>>>> Hi all.. I was playing around with a cluster and wanted to upload a >>>>> configset into Solr…. >>>>> >>>>> I ran bin/solr and noticed a bin/solr config -h command, but it just lets >>>>> me tweak a config. Then I ran bin/solr create -h and it appears to let >>>>> me >>>>> upload a configset, but I have to create the collection as well, and I’m >>>>> not ready to do that. >>>>> >>>>> Then I poked around and discovered hidden under bin/solr zk a command >>>>> upconfig…. So bin/solr zk upconfig will let me get my configset into Solr, >>>>> but does require me to remember what my magic ZK string is ;-). >>>>> >>>>> I went and checked the ref guide, and yes, it states that there are two >>>>> ways: >>>>> >>>>> A configset can be uploaded to ZooKeeper either via the Configsets API < >>>>> https://solr.apache.org/guide/solr/latest/configuration-guide/configsets-api.html> >>>>> or more directly via bin/solr zk upconfig < >>>>> https://solr.apache.org/guide/solr/latest/deployment-guide/solr-control-script-reference.html#upload-a-configuration-set>. >>>>> The Configsets API has some other operations as well, and like
Re: Use cases for interacting direct with ZK versus using our APIs?
Could you share more about “update Solr remotely” that you were doing? Are we missing some APIs that would have made whatever you had to do require ZK direct access? While it’s cool that we can impact Solr via hacking around in ZK, it also seems like an approach fraught with risk! > On Feb 11, 2024, at 11:32 AM, Walter Underwood wrote: > > I wanted something that didn’t require installing Solr locally in order to > update Solr remotely, so I didn’t use the provided zk commands. I wrote some > Python to dig the Zookeeper addresses out of clusterstatus (I think) then > uploaded directly to Zookeeper with the Python kazoo package. > > The tool had a bunch of other things, like async reload checking for results, > and rebuilding suggestion dictionaries on each node. > > wunder > Walter Underwood > wun...@wunderwood.org > http://observer.wunderwood.org/ (my blog) > >> On Feb 11, 2024, at 9:04 AM, Gus Heck wrote: >> >> I pretty much always use zk upconfig, which also works for overwriting >> existing. I certainly tell my clients to use apis from the ref guide for >> such operations, but zk upconfig certainly counts as one. Mostly I tell >> them that they should only break out things like >> https://github.com/rgs1/zk_shell as a last resort (which is what I think of >> as direct modification), and if they are unsure, call me *before* doing >> anything in zk directly. >> >> By the way, I don't know if this has come up in a dev/build setting or not, >> but are you aware of https://plugins.gradle.org/search?term=solr ? It is >> presently only really suitable for local dev, with a single config set, but >> could easily grow patches and suggestions welcome of course. >> >> On Sun, Feb 11, 2024, 9:10 AM Eric Pugh >> wrote: >> >>> Hi all.. I was playing around with a cluster and wanted to upload a >>> configset into Solr…. >>> >>> I ran bin/solr and noticed a bin/solr config -h command, but it just lets >>> me tweak a config. Then I ran bin/solr create -h and it appears to let me >>> upload a configset, but I have to create the collection as well, and I’m >>> not ready to do that. >>> >>> Then I poked around and discovered hidden under bin/solr zk a command >>> upconfig…. So bin/solr zk upconfig will let me get my configset into Solr, >>> but does require me to remember what my magic ZK string is ;-). >>> >>> I went and checked the ref guide, and yes, it states that there are two >>> ways: >>> >>> A configset can be uploaded to ZooKeeper either via the Configsets API < >>> https://solr.apache.org/guide/solr/latest/configuration-guide/configsets-api.html> >>> or more directly via bin/solr zk upconfig < >>> https://solr.apache.org/guide/solr/latest/deployment-guide/solr-control-script-reference.html#upload-a-configuration-set>. >>> The Configsets API has some other operations as well, and likewise, so does >>> the CLI. >>> >>> Are there use cases where interacting directly with ZooKeeper is preferred >>> over making changes via the APIs? Of is the use of bin/solr zk upconfig >>> more of a evolutionary byproduct of how we built SolrCloud? >>> >>> Eric >>> >>> ___ >>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | >>> http://www.opensourceconnections.com < >>> http://www.opensourceconnections.com/> | My Free/Busy < >>> http://tinyurl.com/eric-cal> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >>> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >>> >>> 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 <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Use cases for interacting direct with ZK versus using our APIs?
Hi all.. I was playing around with a cluster and wanted to upload a configset into Solr…. I ran bin/solr and noticed a bin/solr config -h command, but it just lets me tweak a config. Then I ran bin/solr create -h and it appears to let me upload a configset, but I have to create the collection as well, and I’m not ready to do that. Then I poked around and discovered hidden under bin/solr zk a command upconfig…. So bin/solr zk upconfig will let me get my configset into Solr, but does require me to remember what my magic ZK string is ;-). I went and checked the ref guide, and yes, it states that there are two ways: A configset can be uploaded to ZooKeeper either via the Configsets API <https://solr.apache.org/guide/solr/latest/configuration-guide/configsets-api.html> or more directly via bin/solr zk upconfig <https://solr.apache.org/guide/solr/latest/deployment-guide/solr-control-script-reference.html#upload-a-configuration-set>. The Configsets API has some other operations as well, and likewise, so does the CLI. Are there use cases where interacting directly with ZooKeeper is preferred over making changes via the APIs? Of is the use of bin/solr zk upconfig more of a evolutionary byproduct of how we built SolrCloud? Eric ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: CLI: bin/solr bin/post bin/postlogs -- what's happening
Thanks David for weighing in. A big part of pushing the bin/post and
bin/postlogs into bin/solr as subcommands is that then the sub command lives in
Java land, and we just “magically” picked up Windows support.
It feels like right now we are in the worst of all worlds.. We have a mix of
bin/{somescript} that is each implemented slightly different, and then a lot of
nested commands under bin/solr, arguably some which should be their own
commands? Do we then move to bin/create, bin/delete, bin/zk, bin/export,
bin/api ?
I’m also thinking of a future where we have more CLI support, for example a CLI
for running a streaming expression. Or a CLI for all the various commands
that the V2 API’s are exposing, and that would be nice to have be scripted via
a CLI. So bin/split-shard?
It may be that we have a pattern in the future like “bin/server” and
“bin/client” or maybe you have “bin/solr api split-shard” and “bin/solr server
start”, and then commands get grouped like that?
I sometimes dream of having a separate “Solr-cli” sub project that has CLI that
uses tooling like https://oclif.io/ to build something really amazing ;-).
I know someone is going to say “can’t we just use Curl”, and that may work for
some folks, but doing a lot of interactions with Solr require multiple steps,
and that’s where the CLI shines. Add in supporting Basic auth and someday
oAuth, and Curl starts to break down.
> On Jan 30, 2024, at 3:10 PM, David Smiley wrote:
>
> I'm writing this to get input on where we're going in the CLI domain
> with respect to organizational choices of our commands. Looking on
> 9x, I see bin/solr, bin/post, bin/postlogs scripts. Recently, most
> internal command plumbing has been centralized under bin/solr and thus
> you can do "bin/solr post" or "bin/solr postlogs" instead of
> "bin/post" and "bin/postlogs" respectively. Disclaimer: So I hear; I
> haven't tried them.
>
> At this point, I think we have a choice:
> (A) Remove bin/post and bin/postlogs in 10. There's no question the
> code duplication should be eliminated but the question is really about
> the DX (developer user experience). Do we want one shell command,
> "bin/solr" to be all things Solr, not just Solr itself (starting
> Solr), but posting data to Solr (basically a Curl alternative)? It's
> already a kitchen sink of some miscellaneous things, granted. This
> annoys my organizational sensibilities.
> (B) Keep the scripts, but implement them as one-liners calling into
> "bin/solr post" or similar, and possibly not document on the bin/solr
> side that these commands are there as it's just for implementation
> convenience. After all, this was the actual motivation of the changes
> that have happened lately -- it's improving code maintenance/support.
> Good stuff; but do we need to change the DX on users too? Is this
> better for them?
>
> Separately, since there are so many commands in bin/solr that don't
> relate to starting Solr, maybe bin/solr-start should exist? (again,
> could be a one-liner call into one CLI backend for our convenience).
>
> This decision is a matter of taste; it's not really technical.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
> -----
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
http://www.opensourceconnections.com <http://www.opensourceconnections.com/> |
My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
<https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
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.
Re: New branch and feature freeze for Solr 9.5.0
Jason, I tackled SOLR-17068 (the one you reminded me of) and I’d love to get it into 9.5 since right now we have a terrible mish mash of bin/solr post and bin/post in the ref guide and docs. Could someone review https://github.com/apache/solr/pull/2227 and if it looks good could we sneak it into 9.5? Eric > On Jan 26, 2024, at 6:29 PM, Eric Pugh > wrote: > > Backport to branch_9_5 is done. > > >> On Jan 26, 2024, at 1:11 PM, Jason Gerlowski wrote: >> >> Go ahead and backport on your own! I'm still waiting on Lucene 9.9.2, so >> there shouldn't be any branch-contention on my end. >> >> Relatedly, Lucene has their RC1 out there and things look good a day or two >> into their VOTE, so with any luck we'll be able to get a Solr 9.5 RC >> together early next week! >> >> Best, >> >> Jason >> >> On Fri, Jan 26, 2024 at 8:49 AM Eric Pugh wrote: >> >>> I am about to merge SOLR-17112, and will backport it to branch_9x. Jason, >>> do you backport it over to the branch_9_5 or do I? >>> >>> ERic >>> >>> >>> On 2024/01/23 19:08:10 Jason Gerlowski wrote: >>>>> It was hoped SOLR-17112 would make 9.4.1 but it didn't as no PR was >>>> proposed. >>>> >>>>> SOLR-17120 [is] nominated for inclusion in the 9.5.0 release >>>> >>>> Those both sound quick and reasonable; they've got a +1 from me to go >>> into >>>> 9.5 (assuming the contributor decides to continue with SOLR-17112). >>>> >>>>> Considering Lucene 9.9.2 is being planned, I think it would be better >>> to >>>>> upgrade Solr to the to-be-released version so users have to deal with >>>>> fewer upgrade cycles. >>>> >>>> Yeah, that might be best; I hadn't realized we weren't already on the >>>> latest Lucene 9.x. I've created SOLR-17128 to track our Lucene upgrade >>>> once 9.9.2 is available. >>>> >>>> Obviously this is a longer delay than some of the tickets above, and will >>>> mean we won't be cutting a Solr RC this week. We can pick a new date for >>>> the initial Solr 9.5 RC once Lucene 9.9.2 is available. >>>> >>>> Best, >>>> >>>> Jason >>>> >>>> On Tue, Jan 23, 2024 at 1:37 PM Anshum Gupta >>> wrote: >>>> >>>>> Considering Lucene 9.9.2 is being planned, I think it would be better >>> to >>>>> upgrade Solr to the to-be-released version so users have to deal with >>> fewer >>>>> upgrade cycles. >>>>> >>>>> To highlight, there are about 90 odd changes in the Lucene 9.9.x line. >>>>> >>>>> -Anshum >>>>> >>>>> On Tue, Jan 23, 2024 at 8:47 AM David Smiley >>> wrote: >>>>> >>>>>> FYI It was hoped SOLR-17112 >>>>>> https://issues.apache.org/jira/browse/SOLR-17112 "bin/solr script >>>>>> doesn't do ps properly on some systems" would make 9.4.1 but it >>> didn't >>>>>> as no PR was proposed. There still isn't one but a contributor is >>>>>> thinking about it. >>>>>> >>>>>> On Tue, Jan 23, 2024 at 11:30 AM Christine Poerschke (BLOOMBERG/ >>>>>> LONDON) wrote: >>>>>>> >>>>>>> Just to cross-reference things further (Jason is already aware) -- >>>>>> https://issues.apache.org/jira/browse/SOLR-17120 and >>>>>> https://github.com/apache/solr/pull/2214 are nominated for >>> inclusion in >>>>>> the 9.5 release, and as always additional reviews and inputs are >>> welcome. >>>>>>> >>>>>>> Regards, >>>>>>> Christine >>>>>>> >>>>>>> From: dev@solr.apache.org At: 01/22/24 17:30:35 UTCTo: >>>>>> dev@solr.apache.org >>>>>>> Subject: New branch and feature freeze for Solr 9.5.0 >>>>>>> >>>>>>> NOTICE: >>>>>>> >>>>>>> Branch branch_9_5 has been cut and versions updated to 9.6 on the >>>>> stable >>>>>>> branch. >>>>>>> >>>>>>> Please observe the normal rules: >>>>>>> >>>>>>> * No
Re: New branch and feature freeze for Solr 9.5.0
Backport to branch_9_5 is done. > On Jan 26, 2024, at 1:11 PM, Jason Gerlowski wrote: > > Go ahead and backport on your own! I'm still waiting on Lucene 9.9.2, so > there shouldn't be any branch-contention on my end. > > Relatedly, Lucene has their RC1 out there and things look good a day or two > into their VOTE, so with any luck we'll be able to get a Solr 9.5 RC > together early next week! > > Best, > > Jason > > On Fri, Jan 26, 2024 at 8:49 AM Eric Pugh wrote: > >> I am about to merge SOLR-17112, and will backport it to branch_9x. Jason, >> do you backport it over to the branch_9_5 or do I? >> >> ERic >> >> >> On 2024/01/23 19:08:10 Jason Gerlowski wrote: >>>> It was hoped SOLR-17112 would make 9.4.1 but it didn't as no PR was >>> proposed. >>> >>>> SOLR-17120 [is] nominated for inclusion in the 9.5.0 release >>> >>> Those both sound quick and reasonable; they've got a +1 from me to go >> into >>> 9.5 (assuming the contributor decides to continue with SOLR-17112). >>> >>>> Considering Lucene 9.9.2 is being planned, I think it would be better >> to >>>> upgrade Solr to the to-be-released version so users have to deal with >>>> fewer upgrade cycles. >>> >>> Yeah, that might be best; I hadn't realized we weren't already on the >>> latest Lucene 9.x. I've created SOLR-17128 to track our Lucene upgrade >>> once 9.9.2 is available. >>> >>> Obviously this is a longer delay than some of the tickets above, and will >>> mean we won't be cutting a Solr RC this week. We can pick a new date for >>> the initial Solr 9.5 RC once Lucene 9.9.2 is available. >>> >>> Best, >>> >>> Jason >>> >>> On Tue, Jan 23, 2024 at 1:37 PM Anshum Gupta >> wrote: >>> >>>> Considering Lucene 9.9.2 is being planned, I think it would be better >> to >>>> upgrade Solr to the to-be-released version so users have to deal with >> fewer >>>> upgrade cycles. >>>> >>>> To highlight, there are about 90 odd changes in the Lucene 9.9.x line. >>>> >>>> -Anshum >>>> >>>> On Tue, Jan 23, 2024 at 8:47 AM David Smiley >> wrote: >>>> >>>>> FYI It was hoped SOLR-17112 >>>>> https://issues.apache.org/jira/browse/SOLR-17112 "bin/solr script >>>>> doesn't do ps properly on some systems" would make 9.4.1 but it >> didn't >>>>> as no PR was proposed. There still isn't one but a contributor is >>>>> thinking about it. >>>>> >>>>> On Tue, Jan 23, 2024 at 11:30 AM Christine Poerschke (BLOOMBERG/ >>>>> LONDON) wrote: >>>>>> >>>>>> Just to cross-reference things further (Jason is already aware) -- >>>>> https://issues.apache.org/jira/browse/SOLR-17120 and >>>>> https://github.com/apache/solr/pull/2214 are nominated for >> inclusion in >>>>> the 9.5 release, and as always additional reviews and inputs are >> welcome. >>>>>> >>>>>> Regards, >>>>>> Christine >>>>>> >>>>>> From: dev@solr.apache.org At: 01/22/24 17:30:35 UTCTo: >>>>> dev@solr.apache.org >>>>>> Subject: New branch and feature freeze for Solr 9.5.0 >>>>>> >>>>>> NOTICE: >>>>>> >>>>>> Branch branch_9_5 has been cut and versions updated to 9.6 on the >>>> 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 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
Re: PR labeling
When I picked up https://github.com/apache/solr/pull/2225 it was cool to see the “start-script” label! Thanks! > On Jan 26, 2024, at 10:33 AM, Jan Høydahl wrote: > > The StaleBot is now active, running once a day at midnight. > I started in a conservative way, only labeling 10 PRs a day, and setting the > threshold at 60 days. > This gives us some time to evaluate without labeling the entire backlog. > Will be interesting to see whether the Bot results in some fogotten PRs being > completed. > > Jan > >> 8. jan. 2024 kl. 23:10 skrev Jan Høydahl : >> >> Hi, >> >> Got some initial (positive) feedback on the auto-categorization PR and plan >> to merge on Thursday, giving you some more time to review. I feel I have not >> 100% nailed perfect labels. Obviously we can't auto label things like >> feature/bug, or versions, so this is only a "category". Ideally there would >> be a a 1:1 between these "category" labels and the "Components" defined in >> JIRA. But here are 96 different "Components" there, most of them are >> old/irrelevant and not always very good IMO. So I'd rather attempt to align >> JIRA components with whatever we come up with here... >> >> Lucene has just put their StaleBot to work, and I created >> https://github.com/apache/solr/pull/2184 to do the same for Solr. Have a >> look. >> >> Jan >> >>> 6. jan. 2024 kl. 01:21 skrev Jan Høydahl : >>> >>> Hi, >>> >>> We tend to not use the GitHub's PR labels we have defined. >>> So I whipped up https://github.com/apache/solr/pull/2180 which is >>> configured to auto-label PRs based on what files are changed. Feedback >>> welcome. >>> >>> Also, I hope we can implement StaleBot for labeling PRs as stale. Lucene is >>> going to test it, see https://github.com/apache/lucene/pull/12813. If that >>> goes well, let's copy their config :) >>> >>> - Jan >>> >>> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: New branch and feature freeze for Solr 9.5.0
I am about to merge SOLR-17112, and will backport it to branch_9x. Jason, do you backport it over to the branch_9_5 or do I? ERic On 2024/01/23 19:08:10 Jason Gerlowski wrote: > > It was hoped SOLR-17112 would make 9.4.1 but it didn't as no PR was > proposed. > > > SOLR-17120 [is] nominated for inclusion in the 9.5.0 release > > Those both sound quick and reasonable; they've got a +1 from me to go into > 9.5 (assuming the contributor decides to continue with SOLR-17112). > > > Considering Lucene 9.9.2 is being planned, I think it would be better to > > upgrade Solr to the to-be-released version so users have to deal with > > fewer upgrade cycles. > > Yeah, that might be best; I hadn't realized we weren't already on the > latest Lucene 9.x. I've created SOLR-17128 to track our Lucene upgrade > once 9.9.2 is available. > > Obviously this is a longer delay than some of the tickets above, and will > mean we won't be cutting a Solr RC this week. We can pick a new date for > the initial Solr 9.5 RC once Lucene 9.9.2 is available. > > Best, > > Jason > > On Tue, Jan 23, 2024 at 1:37 PM Anshum Gupta wrote: > > > Considering Lucene 9.9.2 is being planned, I think it would be better to > > upgrade Solr to the to-be-released version so users have to deal with fewer > > upgrade cycles. > > > > To highlight, there are about 90 odd changes in the Lucene 9.9.x line. > > > > -Anshum > > > > On Tue, Jan 23, 2024 at 8:47 AM David Smiley wrote: > > > > > FYI It was hoped SOLR-17112 > > > https://issues.apache.org/jira/browse/SOLR-17112 "bin/solr script > > > doesn't do ps properly on some systems" would make 9.4.1 but it didn't > > > as no PR was proposed. There still isn't one but a contributor is > > > thinking about it. > > > > > > On Tue, Jan 23, 2024 at 11:30 AM Christine Poerschke (BLOOMBERG/ > > > LONDON) wrote: > > > > > > > > Just to cross-reference things further (Jason is already aware) -- > > > https://issues.apache.org/jira/browse/SOLR-17120 and > > > https://github.com/apache/solr/pull/2214 are nominated for inclusion in > > > the 9.5 release, and as always additional reviews and inputs are welcome. > > > > > > > > Regards, > > > > Christine > > > > > > > > From: dev@solr.apache.org At: 01/22/24 17:30:35 UTCTo: > > > dev@solr.apache.org > > > > Subject: New branch and feature freeze for Solr 9.5.0 > > > > > > > > NOTICE: > > > > > > > > Branch branch_9_5 has been cut and versions updated to 9.6 on the > > 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 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.5 and priority "Blocker" will > > delay > > > > a release candidate build. > > > > > > > > The feature-freeze for the 9.5 release will go till the end of this > > week > > > - > > > > I'll aim to create our first RC on Thursday, January 25th. > > > > > > > > Best, > > > > > > > > Jason > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > > > > -- > > Anshum Gupta > > > - To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
Re: failing: not ok 3 auth enable/disable lifecycle in 10000ms
Does anyone know how to do this? I have never touched the Jenkins jobs… On Tue, Jan 23, 2024 at 11:50 AM David Smiley wrote: > Please configure it to stop the build after a couple hours. We never > want a build running for longer. > > On Mon, Jan 22, 2024 at 7:53 AM Eric Pugh wrote: > > > > Build https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/168/ has > been running for five days! Guessing it's not going to finish. > > > > I clicked the "Stop" button on the build and will see what happens. I > might let it run another time to see if the test starts behaving, and if > not, then remove the test. I think this needs to get resolved one way or > the other before 9.5 gets cut! > > > > Eric > > > > > > On 2024/01/18 15:00:40 Eric Pugh wrote: > > > Okay, I checked and it looks like the test failed, and is causing the > entire build to hang... > > > > > > https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/168/console > > > > > > The test runs on my local machine just fineAnd it appears to > be running just fine on Solr-Check-main. > > > > > > Is there a way to kill and restart the jenkins build and see if it > happens again? Alternatively I could live with just removing this bats > test from the branch_9x? > > > > > > On 2024/01/17 19:35:26 Eric Pugh wrote: > > > > I hope I did the right thing, which was I fixed the back port by > making a change and committing directly to branch_9x. > > > > > > > > > > > > > https://github.com/apache/solr/commit/acaed85f8544b66b127175df02c798e74dd90ff2 >  > > > > Fix SOLR-16876 backport of bin/solr scripts to work with 9x > SolrCLI.java · apache/solr@acaed85 > > > > github.com > > > > > > > > > > > > I will keep an eye on the Solr-Check-9.x build. > > > > > > > > > > > > > > > > > On Jan 17, 2024, at 11:05 AM, Eric Pugh < > ep...@opensourceconnections.com> wrote: > > > > > > > > > > I will take a look…. > > > > > > > > > >> On Jan 17, 2024, at 10:38 AM, David Smiley > wrote: > > > > >> > > > > >> The integration tests (bats) are failing on branch_9x for me > locally and as > > > > >> also seen in Jenkins. > > > > >>> not ok 3 auth enable/disable lifecycle in 1ms > > > > >> > https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/167/console > > > > >> > > > > >> Hopefully someone has a clue why? > > > > >> > > > > >> ~ David Smiley > > > > >> Apache Lucene/Solr Search Developer > > > > >> http://www.linkedin.com/in/davidwsmiley > > > > > > > > > > ___ > > > > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | > 434.466.1467 | http://www.opensourceconnections.com < > http://www.opensourceconnections.com/> | My Free/Busy < > http://tinyurl.com/eric-cal> > > > > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < > https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw > > > > > > > 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 < > http://www.opensourceconnections.com/> | My Free/Busy < > http://tinyurl.com/eric-cal> > > > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < > https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw > > > > > > 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 > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > - > 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.5.0
Should it be an error?
> On Jan 22, 2024, at 2:35 PM, Jason Gerlowski wrote:
>
>> I'm a little surprised that this isn't caught by the
> 'check'/'precommit' checks - I've been relying (apparently mistakenly) on
> those tasks to catch this sort of thing when reviewing and merging PRs.
>
> Ah, I see why I didn't catch it. It's a warning instead of an error.
> Nevermind my comment. Working on a fix now.
>
> On Mon, Jan 22, 2024 at 2:32 PM Jason Gerlowski
> wrote:
>
>> I've put together a first-draft for our release-notes for 9.5. They're
>> available here:
>> https://cwiki.apache.org/confluence/display/SOLR/DRAFT+ReleaseNote9_5_0
>>
>> Would love some review on what I've put together; feel free to add, remove
>> or change anything as needed!
>>
>> Best,
>>
>> Jason
>>
>> On Mon, Jan 22, 2024 at 2:18 PM Jason Gerlowski
>> wrote:
>>
>>>> I committed a bug in the build for setting up Node with a registry
>>> mirror. I assume it's ok for me to backport?
>>>
>>> Yep, please do!
>>>
>>>> One page has two of the same anchors on branch_9x and branch_9_5. We
>>> should fix this before the release.
>>>
>>> Agreed, I'll take a look.
>>>
>>> Fwiw, I merged the PR that likely created that anchor conflict. I'm a
>>> little surprised that this isn't caught by the 'check'/'precommit' checks -
>>> I've been relying (apparently mistakenly) on those tasks to catch this sort
>>> of thing when reviewing and merging PRs. I guess I'll have to add some
>>> other ref-guide specific task to my pre-merge routine?
>>>
>>> On Mon, Jan 22, 2024 at 1:29 PM Houston Putman
>>> wrote:
>>>
>>>> Hey Jason,
>>>>
>>>> I committed a bug in the build for setting up Node with a registry
>>>> mirror.
>>>> I assume it's ok for me to backport?
>>>>
>>>> Also I noticed that there is an issue with the ref guide. One page has
>>>> two
>>>> of the same anchors on branch_9x and branch_9_5. We should fix this
>>>> before
>>>> the release.
>>>>
>>>>
>>>> {"level":"warn","time":1705948125542,"name":"asciidoctor","file":{"path":"/Users/houstonputman/dev/oss/solr/solr/main/solr/solr-ref-guide/build/site-staging/modules/configuration-guide/pages/coreadmin-api.adoc","line":606},"source":{"url":"file:///Users/houstonputman/dev/oss/solr/solr/main","local":"/Users/houstonputman/dev/oss/solr/solr/main/.git","worktree":"/Users/houstonputman/dev/oss/solr/solr/main","refname":"branch_9_5","reftype":"branch","startPath":"solr/solr-ref-guide/build/site-staging"},"msg":"id
>>>>> assigned to block already in use: v1coreadmin-mergeindexes"}
>>>>>
>>>> {"level":"warn","time":1705948125542,"name":"asciidoctor","file":{"path":"/Users/houstonputman/dev/oss/solr/solr/main/solr/solr-ref-guide/build/site-staging/modules/configuration-guide/pages/coreadmin-api.adoc","line":614},"source":{"url":"file:///Users/houstonputman/dev/oss/solr/solr/main","local":"/Users/houstonputman/dev/oss/solr/solr/main/.git","worktree":"/Users/houstonputman/dev/oss/solr/solr/main","refname":"branch_9_5","reftype":"branch","startPath":"solr/solr-ref-guide/build/site-staging"},"msg":"id
>>>>> assigned to block already in use: v2coreadmin-mergeindexes"}
>>>>>
>>>>
>>>> - Houston
>>>>
>>>> On Mon, Jan 22, 2024 at 12:30 PM Jason Gerlowski
>>>> wrote:
>>>>
>>>>> NOTICE:
>>>>>
>>>>> Branch branch_9_5 has been cut and versions updated to 9.6 on the
>>>> 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 patches you
>>>>> want to commit to Jira first to give others the chance to review
>>>>>
Re: failing: not ok 3 auth enable/disable lifecycle in 10000ms
Build https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/168/ has been running for five days! Guessing it's not going to finish. I clicked the "Stop" button on the build and will see what happens. I might let it run another time to see if the test starts behaving, and if not, then remove the test. I think this needs to get resolved one way or the other before 9.5 gets cut! Eric On 2024/01/18 15:00:40 Eric Pugh wrote: > Okay, I checked and it looks like the test failed, and is causing the entire > build to hang... > > https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/168/console > > The test runs on my local machine just fineAnd it appears to be > running just fine on Solr-Check-main. > > Is there a way to kill and restart the jenkins build and see if it happens > again? Alternatively I could live with just removing this bats test from > the branch_9x? > > On 2024/01/17 19:35:26 Eric Pugh wrote: > > I hope I did the right thing, which was I fixed the back port by making a > > change and committing directly to branch_9x. > > > > > > https://github.com/apache/solr/commit/acaed85f8544b66b127175df02c798e74dd90ff2 > > Fix SOLR-16876 backport of bin/solr scripts to work with 9x SolrCLI.java · > > apache/solr@acaed85 > > github.com > > > > > > I will keep an eye on the Solr-Check-9.x build. > > > > > > > > > On Jan 17, 2024, at 11:05 AM, Eric Pugh > > > wrote: > > > > > > I will take a look…. > > > > > >> On Jan 17, 2024, at 10:38 AM, David Smiley wrote: > > >> > > >> The integration tests (bats) are failing on branch_9x for me locally and > > >> as > > >> also seen in Jenkins. > > >>> not ok 3 auth enable/disable lifecycle in 1ms > > >> https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/167/console > > >> > > >> Hopefully someone has a clue why? > > >> > > >> ~ David Smiley > > >> Apache Lucene/Solr Search Developer > > >> http://www.linkedin.com/in/davidwsmiley > > > > > > ___ > > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > > > http://www.opensourceconnections.com > > > <http://www.opensourceconnections.com/> | My Free/Busy > > > <http://tinyurl.com/eric-cal> > > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > > > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > > > > > 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 > > <http://www.opensourceconnections.com/> | My Free/Busy > > <http://tinyurl.com/eric-cal> > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > > > 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 > > - To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
Re: failing: not ok 3 auth enable/disable lifecycle in 10000ms
Okay, I checked and it looks like the test failed, and is causing the entire build to hang... https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/168/console The test runs on my local machine just fineAnd it appears to be running just fine on Solr-Check-main. Is there a way to kill and restart the jenkins build and see if it happens again? Alternatively I could live with just removing this bats test from the branch_9x? On 2024/01/17 19:35:26 Eric Pugh wrote: > I hope I did the right thing, which was I fixed the back port by making a > change and committing directly to branch_9x. > > > https://github.com/apache/solr/commit/acaed85f8544b66b127175df02c798e74dd90ff2 > Fix SOLR-16876 backport of bin/solr scripts to work with 9x SolrCLI.java · > apache/solr@acaed85 > github.com > > > I will keep an eye on the Solr-Check-9.x build. > > > > > On Jan 17, 2024, at 11:05 AM, Eric Pugh > > wrote: > > > > I will take a look…. > > > >> On Jan 17, 2024, at 10:38 AM, David Smiley wrote: > >> > >> The integration tests (bats) are failing on branch_9x for me locally and as > >> also seen in Jenkins. > >>> not ok 3 auth enable/disable lifecycle in 1ms > >> https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/167/console > >> > >> Hopefully someone has a clue why? > >> > >> ~ David Smiley > >> Apache Lucene/Solr Search Developer > >> http://www.linkedin.com/in/davidwsmiley > > > > ___ > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > > http://www.opensourceconnections.com > > <http://www.opensourceconnections.com/> | My Free/Busy > > <http://tinyurl.com/eric-cal> > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > > > 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 <http://www.opensourceconnections.com/> > | My Free/Busy <http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > 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: failing: not ok 3 auth enable/disable lifecycle in 10000ms
I will take a look…. > On Jan 17, 2024, at 10:38 AM, David Smiley wrote: > > The integration tests (bats) are failing on branch_9x for me locally and as > also seen in Jenkins. >> not ok 3 auth enable/disable lifecycle in 1ms > https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/167/console > > Hopefully someone has a clue why? > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: [DISCUSS] Community Virtual Meetup, January 2024
One more topic would be a discussion about a hackathon that is being proposed for C/C 2024 NA. > On Jan 15, 2024, at 4:04 AM, raghavan m wrote: > > Thanks, Eric. I updated the page with the two topics > > Everyone, > The meetup will be on 01/18 9 am pacific time, 10:30pm IST. > Please submit topics that you would like to discuss here. > https://cwiki.apache.org/confluence/display/SOLR/2024-01-18+Meeting+notes > > https://meet.google.com/wek-upvd-pff > > thanks, > *Raghavan* > > > On Fri, Jan 12, 2024 at 10:19 AM Eric Pugh <mailto:ep...@opensourceconnections.com>> > wrote: > >> I’d be interested in a discussion around: >> >> Standardizing System Property Names and Ramifications: >> https://lists.apache.org/thread/ckb3tqnjf0h66rd0mlpfblpvkrvp3wq6 >> >> Migration from JIRA to Github for issues: >> https://lists.apache.org/thread/7kg0m7528h4xox1hzf5wb26fzcl9758g >> >> I’d love to also share some early plans for a 1 day Hackathon for various >> Search related projects at C / C North America coming up this year. >> >> >> >>> On Jan 11, 2024, at 6:46 PM, raghavan m wrote: >>> >>> Hello everyone >>> So far, 1/18 is the most voted date. I’ll announce in meetup and slack >>> channels, also create a meeting notes page. >>> Please reply to this thread with any agenda/ presentation that you want >> to >>> discuss. >>> >>> Thanks >>> Raghavan >>> >>> Sent from iPhone >>> >>> >>> On Wed, Jan 10, 2024 at 10:42 PM Marcus Eagan >> wrote: >>> >>>> On the 18th, I'll be available to join. >>>> >>>> On Wed, Jan 10, 2024 at 7:06 PM David Smiley >> wrote: >>>> >>>>> 18th >>>>> or probably any >>>>> >>>>> On Wed, Jan 10, 2024 at 12:15 AM raghavan m >>>>> wrote: >>>>> >>>>>> Hey everyone, >>>>>> Please vote for one of the following days >>>>>> >>>>>> - 1/15 >>>>>> - 1/16 >>>>>> - 1/17 >>>>>> - 1/18 >>>>>> - 1/19 >>>>>> - 1/22 >>>>>> >>>>>> Time: 9 am pacific time. >>>>>> Thanks >>>>>> Raghavan >>>>>> >>>>>> Sent from iPhone >>>>>> >>>>>> >>>>>> On Mon, Jan 8, 2024 at 5:27 AM Jason Gerlowski >> >>>>>> wrote: >>>>>> >>>>>>> Awesome, thanks for volunteering Raghavan! >>>>>>> >>>>>>> Anyone have thoughts on scheduling? Absent other strong opinions, >>>>> maybe >>>>>> we >>>>>>> could aim for the week of Monday the 15th through Friday the 19th and >>>>>> pick >>>>>>> a day/time in that range? >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Jason >>>>>>> >>>>>>> On Sun, Jan 7, 2024 at 1:27 AM raghavan m >>>>>> wrote: >>>>>>> >>>>>>>> Happy New Year everyone. I can volunteer for January. >>>>>>>> >>>>>>>> Sent from iPhone >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jan 2, 2024 at 7:49 AM Jason Gerlowski < >>>>> gerlowsk...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey all, >>>>>>>>> >>>>>>>>> After missing December, It's time once again to start thinking >>>>> ahead >>>>>> to >>>>>>>> our >>>>>>>>> first Virtual Meetup in the New Year! As always, there's two >>>> main >>>>>>>>> questions to answer in terms of planning: >>>>>>>>> >>>>>>>>> 1. Any volunteers to organize? Organizer duties are pretty light >>>>> and >>>>>>> are >>>>>>>>> summarized here: >>>>>>>>> https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes. >>>>>>>>> Volunteers >>>>>>>>> get some discretion in terms of
Re: [DISCUSS] Community Virtual Meetup, January 2024
I’d be interested in a discussion around: Standardizing System Property Names and Ramifications: https://lists.apache.org/thread/ckb3tqnjf0h66rd0mlpfblpvkrvp3wq6 Migration from JIRA to Github for issues: https://lists.apache.org/thread/7kg0m7528h4xox1hzf5wb26fzcl9758g I’d love to also share some early plans for a 1 day Hackathon for various Search related projects at C / C North America coming up this year. > On Jan 11, 2024, at 6:46 PM, raghavan m wrote: > > Hello everyone > So far, 1/18 is the most voted date. I’ll announce in meetup and slack > channels, also create a meeting notes page. > Please reply to this thread with any agenda/ presentation that you want to > discuss. > > Thanks > Raghavan > > Sent from iPhone > > > On Wed, Jan 10, 2024 at 10:42 PM Marcus Eagan wrote: > >> On the 18th, I'll be available to join. >> >> On Wed, Jan 10, 2024 at 7:06 PM David Smiley wrote: >> >>> 18th >>> or probably any >>> >>> On Wed, Jan 10, 2024 at 12:15 AM raghavan m >>> wrote: >>> >>>> Hey everyone, >>>> Please vote for one of the following days >>>> >>>> - 1/15 >>>> - 1/16 >>>> - 1/17 >>>> - 1/18 >>>> - 1/19 >>>> - 1/22 >>>> >>>> Time: 9 am pacific time. >>>> Thanks >>>> Raghavan >>>> >>>> Sent from iPhone >>>> >>>> >>>> On Mon, Jan 8, 2024 at 5:27 AM Jason Gerlowski >>>> wrote: >>>> >>>>> Awesome, thanks for volunteering Raghavan! >>>>> >>>>> Anyone have thoughts on scheduling? Absent other strong opinions, >>> maybe >>>> we >>>>> could aim for the week of Monday the 15th through Friday the 19th and >>>> pick >>>>> a day/time in that range? >>>>> >>>>> Best, >>>>> >>>>> Jason >>>>> >>>>> On Sun, Jan 7, 2024 at 1:27 AM raghavan m >>>> wrote: >>>>> >>>>>> Happy New Year everyone. I can volunteer for January. >>>>>> >>>>>> Sent from iPhone >>>>>> >>>>>> >>>>>> On Tue, Jan 2, 2024 at 7:49 AM Jason Gerlowski < >>> gerlowsk...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hey all, >>>>>>> >>>>>>> After missing December, It's time once again to start thinking >>> ahead >>>> to >>>>>> our >>>>>>> first Virtual Meetup in the New Year! As always, there's two >> main >>>>>>> questions to answer in terms of planning: >>>>>>> >>>>>>> 1. Any volunteers to organize? Organizer duties are pretty light >>> and >>>>> are >>>>>>> summarized here: >>>>>>> https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes. >>>>>>> Volunteers >>>>>>> get some discretion in terms of picking a meeting time/day that >>> works >>>>> for >>>>>>> them. If there are no volunteers by the end of the week, I'm >> more >>>> than >>>>>>> happy to set things up for this month. >>>>>>> >>>>>>> 2. When should we meet? I've started the discussion early this >>>> month, >>>>> so >>>>>>> we've got plenty of days to choose from. If you have any >> opinions, >>>>>> please >>>>>>> discuss. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Jason >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> -- >> Marcus Eagan >> ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: [DISCUSS] Community Virtual Meetup, January 2024
I prefer 18,19, or 20….! > On Jan 10, 2024, at 5:18 AM, Alessandro Benedetti > wrote: > > Right now, all of them work for me. > > Cheers > -- > *Alessandro Benedetti* > Director @ Sease Ltd. > *Apache Lucene/Solr Committer* > *Apache Solr PMC Member* > > e-mail: a.benede...@sease.io > > > *Sease* - Information Retrieval Applied > Consulting | Training | Open Source > > Website: Sease.io <http://sease.io/> > LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter > <https://twitter.com/seaseltd> | Youtube > <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github > <https://github.com/seaseltd> > > > On Wed, 10 Jan 2024 at 05:15, raghavan m wrote: > >> Hey everyone, >> Please vote for one of the following days >> >> - 1/15 >> - 1/16 >> - 1/17 >> - 1/18 >> - 1/19 >> - 1/22 >> >> Time: 9 am pacific time. >> Thanks >> Raghavan >> >> Sent from iPhone >> >> >> On Mon, Jan 8, 2024 at 5:27 AM Jason Gerlowski >> wrote: >> >>> Awesome, thanks for volunteering Raghavan! >>> >>> Anyone have thoughts on scheduling? Absent other strong opinions, maybe >> we >>> could aim for the week of Monday the 15th through Friday the 19th and >> pick >>> a day/time in that range? >>> >>> Best, >>> >>> Jason >>> >>> On Sun, Jan 7, 2024 at 1:27 AM raghavan m >> wrote: >>> >>>> Happy New Year everyone. I can volunteer for January. >>>> >>>> Sent from iPhone >>>> >>>> >>>> On Tue, Jan 2, 2024 at 7:49 AM Jason Gerlowski >>>> wrote: >>>> >>>>> Hey all, >>>>> >>>>> After missing December, It's time once again to start thinking ahead >> to >>>> our >>>>> first Virtual Meetup in the New Year! As always, there's two main >>>>> questions to answer in terms of planning: >>>>> >>>>> 1. Any volunteers to organize? Organizer duties are pretty light and >>> are >>>>> summarized here: >>>>> https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes. >>>>> Volunteers >>>>> get some discretion in terms of picking a meeting time/day that works >>> for >>>>> them. If there are no volunteers by the end of the week, I'm more >> than >>>>> happy to set things up for this month. >>>>> >>>>> 2. When should we meet? I've started the discussion early this >> month, >>> so >>>>> we've got plenty of days to choose from. If you have any opinions, >>>> please >>>>> discuss. >>>>> >>>>> Best, >>>>> >>>>> Jason >>>>> >>>> >>> >> ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Basic Auth Support for SolrCLI in 10x.... :-(
I paired with Jason for a while today, and it looks like the effort of back porting the Basic Auth support for the Solr CLI is going to drag along a lot of other parameter changes to various CLI commands…. We talked about it and decided to just leave it on main branch for now. We fixed up the CHANGES.txt to reflect that. Eric ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: V2 API migration
I’m okay with /api…. I suspect by the time we do a v3.. well, It’s a completely new way of interacting with things…. /graph? /virtual_reality_instructions? /chatbot?q=split the latest the shards that are too big for me with no downtime > On Dec 8, 2023, at 9:13 AM, Jason Gerlowski wrote: > > Personally I like "/v2". It's more "future-proof" than "/api", since it > acknowledges that we may want a "v3" someday. But in practice that day is > likely so far off that it's probably not a big deal either way. And I > think in some past discussions about this, "/api" was a mostly unanimous > consensus. Which is why I've been using it in docs, etc. > > (I wish I could find that discussion; I can't remember what the motivations > were...) > > "/v2" isn't deprecated (yet), but I think that route makes sense if there's > still consensus on "/api". Hopefully that's do-able despite some of the > Jetty-filter level challenges Gus mentioned. > > Jason > > On Thu, Dec 7, 2023 at 11:31 PM Gus Heck wrote: > >> I think you will find that this is necessary to avoid /solr/api since all >> the code lives under the /solr web app (and has to go throuh >> SolrDispatchFilter). This sort of thing is why I would someday like to pick >> apart our uber-swiss-army-kinfe-filter (SolrDispatchFilter) and make a >> series of filters. Then the appropriate ones could be re-used around a >> servlet deployed next to /solr called /api... >> >> https://github.com/apache/solr/blob/b14505c19a76e833734dc0c75febc3601f633e37/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L427 >> >> On Thu, Dec 7, 2023 at 10:06 PM David Smiley >> wrote: >> >>> While looking at our jett.xml, I noticed some rewrite rules including a >>> "/v2/*" mapping. >>> >>> >> https://github.com/apache/solr/blob/b14505c19a76e833734dc0c75febc3601f633e37/solr/server/etc/jetty.xml#L142C35-L142C35 >>> >>> Is this considered a deprecated URL pattern for V2 which is now at "/api" >>> if I recall correctly? If so, should we remove this in main (Solr 10)? >> A >>> quick look in JIRA and I couldn't find the umbrella issue to try and >> answer >>> this. I looked at >>> >>> >> https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation >>> and it doesn't mention "/v2" or "/api". >>> >>> I searched the ref guide and see only one page referencing "/v2" -- >>> task-management.adoc >>> >>> ~ David >>> >> >> >> -- >> http://www.needhamsoftware.com (work) >> https://a.co/d/b2sZLD9 (my fantasy fiction book) >> ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Solr 9.4.1
Something that I’d like to get released ASAP is a fix to the bin/solr post command. Our Ref Guide has a lot of mentions of using “bin/solr post -c tech products”, however I removed the -c parameter in favour of -url parameter. I think that was a mistake, and would like to restore the old -c parameter, and then make sure the Ref Guide is up to date. This could be a 9.4.1 or 9.5 change. > On Dec 6, 2023, at 10:31 AM, Jason Gerlowski wrote: > > Good question - I'm still thinking through what makes the most sense > there. Let's continue discussion on SOLR-17100 if you've got thoughts! > > On Wed, Dec 6, 2023 at 9:58 AM Jan Høydahl wrote: > >> Jason, what do you mean by "publishing" the clients? >> I suppose you don't mean pip and npm, but including them in the binary >> tarball for users to consume? Or can we perhaps keep them "internal" only >> for a few releases with no docs and no guarantees, only dog-fooding? >> >> Jan >> >>> 6. des. 2023 kl. 15:38 skrev Jason Gerlowski : >>> >>> I'd love to see a 9.5 go out sometime in January to get our new Python >> and >>> Javascript clients in front of users. I'm willing to RM the release, or >>> share duties with you if you're interested David? Publishing the new >>> clients will require some changes to the release process, and I'd hate to >>> saddle someone else with ironing out whatever hiccups are likely to crop >> up. >>> >>> What do you guys think about doing 9.5 on a January-ish timeframe? >>> >>> That said, if someone else wants a 9.4.1 I don't want to get in the way >> of >>> that either. Jan's right that there'd still be value in a 9.4.1 even >> with >>> a 9.5. I imagine the driving factor would be whether there's a willing >> RM >>> for 9.4.1 >>> >>> >>> >>> On Wed, Dec 6, 2023 at 5:42 AM Jan Høydahl >> wrote: >>> >>>> The benefit of doing 9.4.1 now is that it won't have that unknown >>>> regression that may be lurking in branch_9x now, so it's a much easier >>>> upgrade path for 9.4.0 users. >>>> However, I feel a 9.5 should follow quickly after. There is always room >>>> for a 9.6, 9.7 etc if someone wants to promote newer features, we don't >>>> need to wait for a certain number of new features to release, in my >> mind it >>>> is enought that we have one very interesting feature, or that >2 months >> has >>>> passed. >>>> >>>> I can help backport dependency upgrades. >>>> >>>> Jan >>>> >>>>> 6. des. 2023 kl. 05:50 skrev David Smiley : >>>>> >>>>> Ideally I would have done a 9.4.1 earlier for that one issue... but I >>>>> didn't and kept feeling more and more guilty... so here we are. But >>>> really >>>>> I shouldn't feel too guilty; open-source is volunteering; doing a patch >>>>> release shouldn't be a required punishment for an unfortunate bug. It >>>>> wasn't even a feature I was using in my day-to-day; I was just helping >>>>> someone fix their problem. >>>>> >>>>> BTW a new Lucene release is close so we might to wait a bit on Solr >> 9.5, >>>> so >>>>> maybe we do this 9.4.1. That Lucene release also touches the index >>>> format >>>>> BTW. >>>>> >>>>> ~ David >>>>> >>>>> >>>>> On Tue, Dec 5, 2023 at 8:50 PM Shawn Heisey >> >>>> >>>>> wrote: >>>>> >>>>>> On 12/5/23 16:28, David Smiley wrote: >>>>>>> I didn't know doing 9.5 was an option. If it still is, I would >> prefer >>>> to >>>>>>> do 9.5. What do people think? >>>>>> >>>>>> The 9.5.0 section of CHANGES.txt in main is not as big as that for >>>>>> 9.4.0, but it's not small either. >>>>>> >>>>>> I do not know whether any of those changes are something that the >> author >>>>>> thinks needs to bake for a little while longer. >>>>>> >>>>>> I run a branch_9x snapshot on my little tiny Solr install that gets >> its >>>>>> index from dovecot, and I update it frequently. It hasn't given me >> any >>>>>> trouble. >>>>>> >>>>>> I say go for it. Someday
Re: [PR] SOLR-16835: Add approximate-/select to OAS [solr]
Assuming I understand correctly, this isn’t a new /select end point. It’s still the same familiar /select end point. It’s about making sure that our generated client, which currently supports *some* endpoints in a very structured way, can also be used to issue queries. Right now, the client does some valuable stuff, but frequently you want to issue a query, and you can’t use the client for that side. This lets an end user install one client, and work with both the /select end point, but also the more highly structured apis. > On Nov 30, 2023, at 9:33 AM, Ishan Chattopadhyaya > wrote: > > Having a /select and a similar (approximate) endpoint that is not exactly > like /select but similar will create fragmentation. Having an automatically > generated client is not a goal worthy of sacrificing on API consistency (by > creating a separate /select like endpoint). > > On Wed, 29 Nov, 2023, 10:23 pm gerlowskija (via GitHub), > wrote: > >> >> gerlowskija merged PR #2079: >> URL: https://github.com/apache/solr/pull/2079 >> >> >> -- >> This is an automated message from the Apache Git Service. >> To respond to the message, please log on to GitHub and use the >> URL above to go to the specific comment. >> >> To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org >> >> For queries about this service, please contact Infrastructure at: >> us...@infra.apache.org >> >> >> - >> To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org >> For additional commands, e-mail: issues-h...@solr.apache.org >> >> ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Broken Refguide Links?
Thanks!
> On Nov 16, 2023, at 10:44 AM, Houston Putman wrote:
>
> This should be done now and the 9.3 and 9.4 ref guides have been fixed as
> well (or they will be within 24 hours)
>
> - Houston
>
> On Tue, Nov 7, 2023 at 2:18 PM Houston Putman <mailto:hous...@apache.org>> wrote:
>
>> Well this is my bad. Stupidly used single quotes instead of double quotes
>> when doing https://issues.apache.org/jira/browse/SOLR-16747
>>
>> Will fix.
>>
>> - Houston
>>
>> On Tue, Nov 7, 2023 at 7:34 AM Eric Pugh > <mailto:ep...@opensourceconnections.com>>
>> wrote:
>>
>>> Anyone else seeing lots of cross link error in the docs on main?
>>>
>>>
>>>> Task :solr:solr-ref-guide:buildLocalAntoraSite
>>>
>>> {"level":"error","time":1699360319032,"name":"asciidoctor","file":{"path":"/Users/epugh/Documents/projects/solr-epugh/solr/solr-ref-guide/build/site-staging/modules/upgrade-notes/pages/major-changes-in-solr-9.adoc"},"source":{"url":"
>>> https://github.com/epugh/solr.git","local":"/Users/epugh/Documents/projects/solr-epugh/.git","worktree":"/Users/epugh/Documents/projects/solr-epugh","refname":"SOLR-17016","reftype":"branch","startPath":"solr/solr-ref-guide/build/site-staging"},"msg":"target
>>> of xref not found: upgrade-notes:major-changes-in-solr-9.html#solr-8-2"}
>>>
>>> {"level":"error","time":1699360319033,"name":"asciidoctor","file":{"path":"/Users/epugh/Documents/projects/solr-epugh/solr/solr-ref-guide/build/site-staging/modules/upgrade-notes/pages/major-changes-in-solr-9.adoc"},"source":{"url":"
>>> https://github.com/epugh/solr.git","local":"/Users/epugh/Documents/projects/solr-epugh/.git","worktree":"/Users/epugh/Documents/projects/solr-epugh","refname":"SOLR-17016","reftype":"branch","startPath":"solr/solr-ref-guide/build/site-staging"},"msg":"target
>>> of xref not found:
>>> configuration-guide:commits-transaction-logs.html#hard-commits-vs-soft-commits”}
>>>
>>> ___
>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
>>> http://www.opensourceconnections.com <
>>> http://www.opensourceconnections.com/> | My Free/Busy <
>>> http://tinyurl.com/eric-cal>
>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
>>> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>>>
>>> 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 <http://www.opensourceconnections.com/> |
My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
<https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
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.
Re: [DISCUSS] Community Virtual Meetup, November 2023
I would love to demo taking a sentiment analysis model from Hugging face and using it to enrich documents via Update Request Processor. Eric > On Nov 14, 2023, at 11:31 AM, Jason Gerlowski wrote: > > Awesome, thanks for volunteering once again Raghavan! > > Now to pick a time and meet! We probably want to avoid at least the latter > half of next week (Nov 22-24) as US-based folks may be out on holiday. > > > > I had a few topics in mind for discussion that I wanted to mention here for > fear that I might forget them. I'll move them to the Meeting page once > that's created: > > - New Contributor PR Review (a followup from an idea discussed last month) > - Update on OpenAPI-Generated Clients > > On Tue, Nov 14, 2023 at 11:26 AM raghavan m wrote: > >> I can volunteer to organize. >> Sent from iPhone >> >> >> On Tue, Nov 14, 2023 at 8:21 AM Jason Gerlowski >> wrote: >> >>> Hey all, >>> >>> It's time once again to start thinking ahead to our Virtual Meetup for >>> November. As always, there's two main questions to answer in terms of >>> planning: >>> >>> 1. Any volunteers to organize? Organizer duties are pretty light and >>> are summarized here: >>> https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes. >>> Volunteers get some discretion in terms of picking a meeting time/day >>> that works for them. If there are no volunteers by the end of the week, >>> I'm >>> more than happy to set things up for this month. >>> >>> 2. When should we meet? It's already a good bit into the month, so >>> we'll have to plan for the latter half. If you have any >>> opinions, please discuss. >>> >>> Best, >>> >>> Jason >>> >> ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Broken Refguide Links?
Anyone else seeing lots of cross link error in the docs on main?
> Task :solr:solr-ref-guide:buildLocalAntoraSite
{"level":"error","time":1699360319032,"name":"asciidoctor","file":{"path":"/Users/epugh/Documents/projects/solr-epugh/solr/solr-ref-guide/build/site-staging/modules/upgrade-notes/pages/major-changes-in-solr-9.adoc"},"source":{"url":"https://github.com/epugh/solr.git","local":"/Users/epugh/Documents/projects/solr-epugh/.git","worktree":"/Users/epugh/Documents/projects/solr-epugh","refname":"SOLR-17016","reftype":"branch","startPath":"solr/solr-ref-guide/build/site-staging"},"msg":"target
of xref not found: upgrade-notes:major-changes-in-solr-9.html#solr-8-2"}
{"level":"error","time":1699360319033,"name":"asciidoctor","file":{"path":"/Users/epugh/Documents/projects/solr-epugh/solr/solr-ref-guide/build/site-staging/modules/upgrade-notes/pages/major-changes-in-solr-9.adoc"},"source":{"url":"https://github.com/epugh/solr.git","local":"/Users/epugh/Documents/projects/solr-epugh/.git","worktree":"/Users/epugh/Documents/projects/solr-epugh","refname":"SOLR-17016","reftype":"branch","startPath":"solr/solr-ref-guide/build/site-staging"},"msg":"target
of xref not found:
configuration-guide:commits-transaction-logs.html#hard-commits-vs-soft-commits”}
___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
http://www.opensourceconnections.com <http://www.opensourceconnections.com/> |
My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
<https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
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.
Re: Apache Solr Newsletter proposal September 2023
end feeling free to be loose on the >> periodicity. Maybe shoot for bi-monthly-ish? I think publishing soon >> after a new release (we just did 9.4!) could be really useful for users >> that might just want to pay attention to the newsletter for news on >> releases. >> >> Thanks again. Looking forward to further discussion! >> >> ~ David >> >> >> On Mon, Oct 16, 2023 at 10:17 AM Jason Gerlowski >> wrote: >> >>> Hi Alejandro, >>> >>> Thanks for taking the initiative on this! You should now have >>> permission to create and edit pages in Confluence - let me know if >>> you're not seeing that on your end. Happy to help with some >>> copy-editing once it's up there! >>> >>> Since this is the first of these newsletter proposals, maybe we should >>> also use this thread to discuss a few "process" questions around the >>> newsletter? (Or maybe I missed these getting discussed elsewhere?) >>> >>> The biggest question I was curious about: what does "publication" look >>> like for these newsletters? Will it be published in "Confluence", or >>> are we using Confluence for editing before eventually publishing in >>> some other medium like annou...@solr.apache.org, the Solr website, >>> etc. >>> >>> Best, >>> >>> Jason >>> >>> On Thu, Oct 12, 2023 at 7:09 PM Arrieta, Alejandro >>> wrote: >>>> >>>> Hello Team, >>>> >>>> Newsletter on ASF social media: >>>> I just returned home from Community over Code, where I talked with the >>>> Asfinfra team, and they redirected me to talk with Brian Proffit. >>>> I talked with him about the new Solr newsletter, and he told me to send >>> him >>>> what we want to publish, the date to publish, and the email with a copy >>> to >>>> the Solr PMC chair. >>>> David Smiley, please confirm you are okay so I can email Brian to publish >>>> the September 2023 newsletter. >>>> >>>> Apache Solr wiki newsletter: >>>> As discussed during the conference, please give me edit authorization to >>>> Solr Wiki to start uploading the newsletter there. My account should be >>>> aarrieta and email aarri...@perrinsoftware.com >>>> >>>> Linkedin Apache Solr account/group: >>>> The Asinfra team told me they do not create social media accounts. These >>>> are created and managed by each project. We can request templates and >>>> publishing guides from pr...@apache.org and mmp group. >>>> >>>> Kind Regards, >>>> Alejandro Arrieta >>>> >>>> >>>> On Tue, Oct 10, 2023 at 9:43 AM Bruno Roustant >>> >>>> wrote: >>>> >>>>> +1 ! >>>>> >>>>> Le lun. 9 oct. 2023 à 16:54, Eric Pugh < >>> ep...@opensourceconnections.com> a >>>>> écrit : >>>>> >>>>>> I’d love to see it on mastodon/twitterX/linkedin too…. I bet ASF PR >>>>>> would love to see this as well ;-) >>>>>> >>>>>>> On Oct 8, 2023, at 5:36 PM, Alessandro Benedetti < >>> a.benede...@sease.io >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> +1 I think it's a wonderful idea! >>>>>>> >>>>>>> On Sun, 8 Oct 2023, 17:26 Arrieta, Alejandro, < >>>>>> aarri...@perrinsoftware.com> >>>>>>> wrote: >>>>>>> >>>>>>>> 0. Intro >>>>>>>> Welcome to the Apache Solr Newsletter proposal September 2023. As >>> this >>>>>> is >>>>>>>> the first newsletter proposal of 2023 we include Solr Community >>> news >>>>>>>> starting from January 2023: >>>>>>>> >>>>>>>> Welcome Alex Deparvu as Solr committer: >>>>>>>> https://lists.apache.org/thread/fx4o3y55ypqy1n06kdbq5k8h4pjxlowj >>>>>>>> >>>>>>>> Welcome Marcus Eagan as Solr committer: >>>>>>>> https://lists.apache.org/thread/2p2fjm18g39x2mknxqnbr3gfcx0q6rrx >>>>>>>> >>>>>>>> Welcome David Smiley as Solr's new PMC chair: >>>>>>>> https:
BATS tests failing on main
I just checked Jenkins https://builds.apache.org/job/Solr/job/Solr-Check-main/lastBuild/console and noticed that the BATS tests appear to be failing. Judging from the error message, we have some Solr processes running that aren’t getting cleaned up properly.. Even by the test_zz_cleanup.bats test? This makes any of the bats test that assume no Solr’s running to see some, and then fail. not ok 76 status detects locally running solr in 3751ms not ok 78 status help flag outputs message highlighting not to use solrUrl. in 3769ms not ok 84 Cleanup in 4785ms ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: [DISCUSS] Community Virtual Meetup, October 2023
Looking forward to it, I like option 1 too. > On Oct 16, 2023, at 2:05 PM, Ishan Chattopadhyaya > wrote: > > Thanks Alejandro. I vote option 1 (26th) > > On Mon, 16 Oct, 2023, 8:38 pm Arrieta, Alejandro, < > aarri...@perrinsoftware.com> wrote: > >> Hello Team, >> >> 1) pick me >> >> 2) proposed dates/time >> Thursday, Oct 26th, 9 AM Pacific/12PM US East >> or >> Friday, Oct 27th, 9 AM Pacific/12PM US East >> To have at least one week to promote the event. >> The vote should end Wednesday, Oct 18th, 11:59 PM Pacific, to publish the >> meetup link on Thursday, Oct 19th. >> >> Kind Regards, >> Alejandro Arrieta >> >> On Mon, Oct 16, 2023 at 9:40 AM Jason Gerlowski >> wrote: >> >>> Hey all, >>> >>> It's time once again to start thinking ahead to our Virtual Meetup for >>> October. As always, there's two main questions to answer in terms of >>> planning: >>> >>> 1. Any volunteers to organize? Organizer duties are pretty light and >>> are summarized here: >>> https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes. >>> Volunteers get some discretion in terms of picking a meeting time/day >>> that works for them. If there are no volunteers by mid-week or so, I'm >>> more than happy to set things up for this month. >>> >>> 2. When should we meet? It's already a good bit into the month, so >>> we'll have to plan for the latter half. If you have any >>> opinions, please discuss. >>> >>> Best, >>> >>> Jason >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>> For additional commands, e-mail: dev-h...@solr.apache.org >>> >>> >> ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Some help needed to complete the release
Alex, what is the process for getting updated Docker images published? Someone pinged me about the 9.4 image. Is that part of the release process. On 2023/10/16 15:32:29 Alex Deparvu wrote: > This marks the final steps of the 9.4.0 release as completed! > Thank you everyone for the continued help in getting this release out! > > best, > alex > > > On Mon, Oct 16, 2023 at 8:26 AM Alex Deparvu wrote: > > > > Thank you Jason! Everything looks great. > > > > On Mon, Oct 16, 2023 at 7:32 AM Jason Gerlowski > > wrote: > > > > > > Hey Alex, > > > > > > I've updated wikidata and added the release via the "Apache Release > > > Reporter". Let me know if anything looks off, particularly with the > > > wikidata changes. > > > > > > Best, > > > > > > Jason > > > > > > On Sun, Oct 15, 2023 at 5:35 PM Alex Deparvu wrote: > > > > > > > > Thank you for checking Alejandro! > > > > Indeed I checked from my phone now and it looks good! Strange probably a > > > > browser cache issue. > > > > > > > > On Sun, Oct 15, 2023 at 14:18 Arrieta, Alejandro < > > > > aarri...@perrinsoftware.com> wrote: > > > > > > > > > Hello Alex, > > > > > > > > > > Thanks for the release! :-) > > > > > > > > > > I do not see 9.4-beta anywhere on > > > > > https://solr.apache.org/guide/solr/9_4/index.html (redirects to > > > > > https://solr.apache.org/guide/solr/latest/index.html) > > > > > If going from https://solr.apache.org/ -> resources -> reference guide > > > > > points to > > > > > https://solr.apache.org/guide > > > > > redirects to > > > > > https://solr.apache.org/guide/solr/latest/index.html > > > > > beta not on the menus to select the version, they show 9.4 and inside > > > > > the > > > > > doc for example: > > > > > > > > > > There are three separate packages: > > > > > > > > > >- > > > > > > > > > >solr-9.4.0.tgz the full binary package, for all operating systems. > > > > > This > > > > >package includes all first-party Solr modules and accessories > > > > > (e.g. the > > > > >prometheus-exporter). > > > > >- > > > > > > > > > >solr-9.4.0-slim.tgz the slim binary package, for all operating > > > > > systems. > > > > >This package only includes what is necessary to run Solr. Modules > > > > > and > > > > >accessories (e.g. the prometheus-exporter) are not included. > > > > >- > > > > > > > > > >solr-9.4.0-src.tgz the package Solr source code. This is useful if > > > > > you > > > > >want to develop on Solr without using the official Git repository. > > > > > > > > > > Maybe there is a cache issue in your browser or latency on the > > > > > refresh of > > > > > the pages (cdn)? > > > > > > > > > > I hope this helps. > > > > > > > > > > Kind Regards. > > > > > Alejandro Arrieta > > > > > > > > > > On Sun, Oct 15, 2023 at 5:27 PM Alex Deparvu > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I am completing the 9.4 release and I need some help with these > > > > > > steps > > > > > > > > > > > > The RefGuide version shows as `9.4-beta`: I have published > > > > > > everything > > > > > > following the wizard but the guide version shows up as 9.4-beta I > > > > > probably > > > > > > forgot to check some box somewhere. > > > > > > https://solr.apache.org/guide/solr/9_4/index.html > > > > > > > > > > > > Step `8 - Announce the release`. > > > > > > > > > > > > > 4 - Add the new version to Wikipedia > > > > > > > > > > > > I don't have an account on wikidata.org - can anyone update this > > > > > > page, > > > > > or > > > > > > should I create an account just for this release? > > > > > > > > > > > > > 5 - Add the new version to the Apache Release Reporter > > > > > > > > > > > > This is only available to PMC members: > > > > > > "Could not save. Make sure you have filled out all fields and have > > > > > > access > > > > > > to this committee data! For further inquiries, please contact > > > > > > d...@community.apache.org > > > > > > Error: User stillalex not a member of PMC solr nor an ASF member" > > > > > > > > > > > > I am thinking a PMC member could help do this, as it's a 5 second > > > > > > task. > > > > > > > > > > > > > > > > > > thanks, > > > > > > alex > > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
Re: Build Upgraded to Gradle 8.4
Wonderful news! It feels great to know we aren’t a major version behind on one of key dependencies! Thanks for the build magic. > On Oct 12, 2023, at 1:15 PM, Kevin Risden wrote: > > Just pushed to main/branch_9x Gradle 8.4 upgrade. Let me know if you see > any weirdness. > > Google Java Format was upgraded so there is a tidy commit that made a bunch > of whitespace changes. If you have PRs in progress, probably need to make > sure tidy is run after getting up to date with main/branch_9x. > > Kevin Risden ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Apache Solr Newsletter proposal September 2023
I’d love to see it on mastodon/twitterX/linkedin too…. I bet ASF PR would love to see this as well ;-) > On Oct 8, 2023, at 5:36 PM, Alessandro Benedetti wrote: > > +1 I think it's a wonderful idea! > > On Sun, 8 Oct 2023, 17:26 Arrieta, Alejandro, > wrote: > >> 0. Intro >> Welcome to the Apache Solr Newsletter proposal September 2023. As this is >> the first newsletter proposal of 2023 we include Solr Community news >> starting from January 2023: >> >> Welcome Alex Deparvu as Solr committer: >> https://lists.apache.org/thread/fx4o3y55ypqy1n06kdbq5k8h4pjxlowj >> >> Welcome Marcus Eagan as Solr committer: >> https://lists.apache.org/thread/2p2fjm18g39x2mknxqnbr3gfcx0q6rrx >> >> Welcome David Smiley as Solr's new PMC chair: >> https://lists.apache.org/thread/yrp2yll52r0fm2pbhw17b62oln63fp33 >> >> Welcome Andy Webb as Solr committer: >> https://lists.apache.org/thread/k449v7jl4bwg6f7x707tvw5ch2dk8h3f >> >> Welcome Justin Sweeney as Solr committer: >> https://lists.apache.org/thread/g588106pohdwok7gpwwcsxpgvwxwwh41 >> >> Welcome Colvin Cowie as Solr committer: >> https://lists.apache.org/thread/ngzjs0b3mb201d2shfvzdysdd5g6xqz1 >> >> 1. Current versions >> Solr 9.3.0: >> https://solr.apache.org/downloads.html#solr-930 >> >> Solr 8.11.2: >> https://solr.apache.org/downloads.html#solr-8112 >> >> Solr Operator v0.7.1: >> https://solr.apache.org/operator/artifacts.html#solr-v071 >> >> 2. Incoming versions >> Solr 9.4.0 >> mailing list thread: >> https://lists.apache.org/thread/j44golmqp4sjf2rk74pqktkrsc1do58r >> >> Solr 8.11.3 >> mailing list thread: >> https://lists.apache.org/thread/j44golmqp4sjf2rk74pqktkrsc1do58r >> >> 3. Solr Improvement Proposals News >> SIP-13: Cross Data Center Replication >> mailing list thread: >> https://lists.apache.org/thread/9y2qd7rs45049xbrt0gty40m4b5cv22y >> wiki link: >> >> https://cwiki.apache.org/confluence/display/SOLR/SIP-13%3A+Cross+Data+Center+Replication >> >> SIP-14 Embedded Zookeeper >> mailing list thread: >> https://lists.apache.org/thread/mch6y4wsbqykcmfy4r76movmx1wz0375 >> wiki link: >> https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper >> >> SIP-15 Node roles >> mailing list thread: >> https://lists.apache.org/thread/kwq609jxckpdqk54fvghxs66jtk92kof >> wiki link: >> https://cwiki.apache.org/confluence/display/SOLR/SIP-15+Node+roles >> >> SIP-19 Adopt JSR-330 dependency injection >> mailing list thread: >> https://lists.apache.org/thread/9y2qd7rs45049xbrt0gty40m4b5cv22y >> wiki link: >> >> https://cwiki.apache.org/confluence/display/SOLR/SIP-19+Adopt+JSR-330+dependency+injection >> >> 4. Links to blogs, videos, others related to Solr: >> Apache Solr Community Virtual Meetup, September 2023: >> >> https://www.meetup.com/apache-solr-virtual-community-meetups/events/296344421/ >> >> DataImportHandler 9.3.0 released: >> https://lists.apache.org/thread/8z65tf4jr2ppdm4xo5r1bygjzt8z8r3f >> >> 5. Upcoming Events & meetings >> ASF Community over Code in Halifax, October 7-10 2023: >> https://communityovercode.org/ >> >> Apache Solr Community Virtual Meetup, October 2023: >> https://www.meetup.com/apache-solr-virtual-community-meetups/events/ >> >> 6. Connect with the Apache Solr Community >> Subscribe to Apache Solr Virtual Meetup for monthly meeting: >> https://www.meetup.com/apache-solr-virtual-community-meetups/ >> >> Follow us on Twitter/X: >> https://twitter.com/apachesolr >> >> Visit our mailing list, jira, irc and slack: >> https://solr.apache.org/community.html >> >> How to contribute: >> https://solr.apache.org/community.html#how-to-contribute >> >> Apache Solr website: >> https://solr.apache.org/ >> >> Apache Solr Operator website: >> https://solr.apache.org/operator/ >> >> Note: This is a proposal and I will start working on the October 2023 >> newsletter proposal and create a Jira to accept contributions. Maybe we can >> publish this on the Apache Solr web if accepted in the future. >> >> Kind Regards, >> Alejandro Arrieta >> ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Community over Code Apache Solr Hackathon
Folks headed to Halifax…. Jason and I have talked about hacking together on Solr during the conference. Well, Good News! I’ve got us a room, thanks to Brian Proffitt's help, to use on Sunday (the day after the Search Track). When you check the conference schedule you should see it show up. Room 107 on Sunday from 10:25-18:30. Jason G and I are planning on spiking out what it would take to fire up a Solr cloud node with the role “zookeeper” and see if we can build a quorum ;-). Other things that would be interesting is to show folks who aren’t deep in Solr code how to build Solr, how to write tests.If we are super energetic, maybe I can talk folks like Jeff Zemerick from OpenNLP community to work with us in loading models into Solr via ONNX ;-). So basically, anything anyone wants to work on ;-). So please come join us in Room 107 on Sunday! Eric ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Crave is doing well
Agreed on the branch merging. It’s been great to have it running the full set of tests! > On Oct 5, 2023, at 10:58 PM, David Smiley wrote: > > I believe the Crave issues with branch merging seem to have been fixed. If > someone sees otherwise, please let me know. > > And boy Crave is fast! The whole GHA action takes 8m but Crave side is 6m of > which 4m of it is tests running. It's faster than "precommit" will is still > running in a standard GHA. Isn't that crazy! Yes, there's room for > improvement. > > There are opportunities for Crave to come up with a GHA self hosted runner to > substantially eat away at that 2m, like a needless checkout of all the code > on the GHA side that basically isn't used. > > There are opportunities for our project to try to optimize the Gradle build > so that it can start running tests (or whatever task) as soon as possible no > matter where it runs. There's a whole section to the Gradle docs on build > optimization. Maybe someone would like to explore that, like trying the > "configuration cache" > https://docs.gradle.org/current/userguide/configuration_cache.html > > I have access to build analytics in Crave that give some insights: The first > 48 seconds is not very concurrent and not downloading anything. The next 36 > seconds it downloads 100MB of something (don't know what). Then CPUs go full > tilt with tests. It's very apparent that Gradle testing has no "work > stealing" algorithm amongst the runners. > > > > I'm a bit perplexed at the downloading of 100MB because the image for the > build machine has commands I added to pre-download stuff. That looks like > the following: > > # Pre-download what we can through Gradle > ./gradlew --write-verification-metadata sha256 --dry-run > rm gradle/verification-metadata.dryrun.xml > ./gradlew -p solr/solr-ref-guide downloadAntora > ./gradlew -p solr/packaging downloadBats > # May need more memory > sed -i 's/-Xmx1g/-Xmx2g/g' gradle.properties > # Use lots of CPUs > sed -i 's/org.gradle.workers.max=.*/org.gradle.workers.max=96/' > gradle.properties > sed -i 's/tests.jvms=.*/tests.jvms=96/' gradle.properties > > ./gradlew assemble || true > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley ___ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
Re: Feedback on changing signature of two commands...
Yeah, the -u for credentials came out of Curl as well ;-). One less thing to remember. As far as -c, both AssertTool and PackageTool use that already as a short option, so the same issue applies. I worry that a lot of folks will learn the -u user:password pattern, and then get caught by Assert and Package over time... > On Oct 2, 2023, at 2:52 PM, Ishan Chattopadhyaya > wrote: > > How about using -u and --credentials for all other commands, but for those > two commands using -c and --credentials? > I like -u for credentials because curl supports that. > > > On Tue, 3 Oct 2023 at 00:13, Eric Pugh <mailto:ep...@opensourceconnections.com>> > wrote: > >> In SOLR-14496, we introduce Basic Auth support using the command line long >> option “-credentials” and the short form “-u”.This dropped in >> seamlessly except for two commands, AssertTool and PackageTool. >> >> AssertTool uses the -u parameter to mean “Asserts that we run as same user >> that owns .” And is short for -same-user parameter. >> >> PackageTool uses the -u parameter to mean "If a deployment is an update >> over a previous deployment.” And is short for -update parameter. >> >> Thoughts on removing those short options (or if we have ideas for a new >> short option using that) so that -u can mean username:password everywhere? >> >> Alternatively is there another short letter for user credentials we >> prefer? -u and —credentials is also what the Prometheus Exporter uses for >> basic auth credentials… >> >> Eric >> >> ___ >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >> 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 <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> 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.
