Hmm, the threading on this is probably unclear. The last message was in response to
"Making zookeeper optional would go a long way for user goodwill and adoption." On Sat, Sep 6, 2025 at 9:19 PM Gus Heck <gus.h...@gmail.com> wrote: > This is one of those things I find perpetually amusing and I blame it > mostly on insufficient documentation *in solr docs* for securing and > configuring ZK. Every large Elastic/ES cluster has an odd number of > dedicated master nodes ... which is analogous to having a zookeeper cluster > (the classic example in ES/OS is 3 master, 5 data, where for us it is 3 zk > and 5 solr)... except for ES/OS it has the same product name so everyone > sees it as simpler. The only real way they are right is that the nodes can > share an authz/authn scheme, and one can more easily waste resources by > giving the master nodes equal sized hardware (if one isn't paying > attention). > > What we probably need here is to complete the embedded ZK SIP > <https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper> > and then we too can have solr nodes with "master" roles (that just run > embedded ZK and nothing else)... but it won't *sound* like a "2nd > technology" that needs to be managed separately. > > Until then we should write docs that explicitly compare this to ES/OS. > > -Gus > > On Fri, Sep 5, 2025 at 3:40 PM matthew sporleder <msporle...@gmail.com> > wrote: > >> On Fri, Sep 5, 2025 at 11:07 AM Ishan Chattopadhyaya >> <ichattopadhy...@gmail.com> wrote: >> > >> > Thank you for your feedback, Andrew. I appreciate your candour and >> passion. >> > >> > On Fri, 5 Sept 2025 at 12:40, Andrew Hankinson >> > <andrew.hankinson@rism.digital> wrote: >> > >> > > I would guess that most, if not all, members of this list have done an >> > > evaluation where they put Solr up against ES/OS, and chose Solr for >> one >> > > reason or another. >> > > This is not a zero-sum game. >> > >> > >> > For fresh adoption, unfortunately it is. As you said, those who have >> > already chosen Solr know why they chose: my intention is not to do >> anything >> > different for them. >> > >> > >> > > If you feel so strongly that Solr is currently a "cesspool of >> mediocrity," >> > > then maybe you need to find something that better fits your own needs >> and >> > > standards of quality. There are some (many?) of us who value the >> stability, >> > > and consistent incremental improvements without requiring massive >> amounts >> > > of rewrites at every release because somebody thinks they need to >> follow >> > > the latest fad. >> > > >> > >> > I've upgraded Solr to Lucene 10 (SOLR-17631), it should take care of >> those >> > who value stability and incremental improvements, esp. performance. >> > >> > >> > > >> > > Your list seems to be written from the perspective of someone who >> does not >> > > actually need to take responsibility for the features that you seem to >> > > think we need. When I see lists like this I, and probably most >> professional >> > > programmers, see a mountain of bugs and support questions all coming >> at >> > > once, on top of the work to plan, write, and test the code. >> Incremental >> > > improvements are a way to make these manageable. That, and most of >> your >> > > stuff means Solr needs to replicate functionality that is already >> > > available. If I need a Kibana / Dashboards setup, I will use that -- >> I'm >> > > not going to be religious about not using it just because the >> underlying >> > > search engine. These are tools, not religions. >> > > >> > >> > Unfortunately, there's nothing close to as good as Kibana or OpenSearch >> > Dashboards for Solr to my knowledge. There used to be a fork of Kibana >> for >> > Solr (called Banana, by Andrew T of Lucidworks), but that project has >> > likely gone stale. >> > >> > >> > > There are also opportunities in your list of requests for you to >> > > contribute back. The easiest way to get some of your requests into >> Solr is >> > > to take it responsibility for it, plan, write, test, and go through >> the >> > > review process, and commit to helping maintain it. Perhaps if you >> were to >> > > choose one of your items and do that, you would get a feeling for how >> much >> > > work you're actually talking about here, rather than (what seems like) >> > > firing off a set of your demands for people to contribute their own >> time >> > > and money so that you can live in your "happy bubble". >> > > >> > > -Andrew >> > > >> > > > On 5 Sep 2025, at 02:47, Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com> >> > > wrote: >> > > > >> > > >> Your list has cool stuff but I think mostly can ship at whatever >> minor >> > > > version. Solr has seen incremental progress over the years at minor >> > > > releases. >> > > > >> > > > If we don't ship headline grabbing features in a major release, we >> might >> > > as >> > > > well abandon this project and dedicate our focus on building >> OpenSearch >> > > or >> > > > Elasticsearch. >> > > > We have had so many important features in Apache Solr introduced in >> some >> > > > incremental release in 9.x. But, what is the perception among users >> about >> > > > Solr's capabilities? I will not say here what I believe people >> think of >> > > > Apache Solr in 2025, lest you or others shoot down the messenger of >> bad >> > > > news, just to stay in a happy bubble. >> > > > >> > > >> FWIW I think Solr 11 is very likely to occur within a year >> following >> > > Solr >> > > >> 10. Maybe that's the release of your dreams, but progress will be >> > > >> incremental (delivering value sooner). >> > > > >> > > > It would be very unfortunate to let Apache Solr languish in a >> cesspool of >> > > > mediocrity for an entire release cycle. >> > > > >> > > > >> > > > On Fri, 5 Sept 2025 at 02:38, David Smiley <dsmi...@apache.org> >> wrote: >> > > > >> > > >> I suppose we all have our wish list of what we want the next major >> > > version >> > > >> to have. I have mine (mostly geeky internal details BTW).... and >> as the >> > > >> need to release draws near, I get more realistic as to what >> limited time >> > > >> resources I'm going to spend on what topic. What can wait vs what >> > > "needs" >> > > >> to happen at a major version boundary. For many existing Solr >> users, >> > > their >> > > >> *pressing* needs will be met with up to date versions Java & Jetty >> & >> > > Lucene >> > > >> -- all things present in Solr 10 right now. Your list has cool >> stuff >> > > but I >> > > >> think mostly can ship at whatever minor version. Some highly >> wanted >> > > things >> > > >> will come to 9.x. Solr has seen incremental progress over the >> years at >> > > >> minor releases. The major releases are not that significant >> except for >> > > an >> > > >> opportunity to break compatibility in some way. That is really >> > > important >> > > >> for us stewarding a project that's been around for almost 20 years >> -- we >> > > >> have to get rid of things or change things. >> > > >> >> > > >> FWIW I think Solr 11 is very likely to occur within a year >> following >> > > Solr >> > > >> 10. Maybe that's the release of your dreams, but progress will be >> > > >> incremental (delivering value sooner). >> > > >> >> > > >> On Thu, Sep 4, 2025 at 2:42 PM Ishan Chattopadhyaya < >> > > >> ichattopadhy...@gmail.com> wrote: >> > > >> >> > > >>> Hi All, >> > > >>> >> > > >>> Here's my wishlist for Solr 10, to make Solr claw back the >> lost/losing >> > > >>> mindshare amongst developers and AI practitioners. >> > > >>> >> > > >>> Here's what I think Solr 10 release should have (in addition to >> > > whatever >> > > >> we >> > > >>> already have): >> > > >>> >> > > >>> ** Vector Search / AI* >> > > >>> - GPU based HNSW indexing >> > > >>> - Local embeddings generation >> > > >>> - Multi-vector fields >> > > >>> - Visualization, metrics, recipes >> > > >>> - Easy integration with storage and inference platforms like >> Sagemaker, >> > > >>> Nemo, AWS S3 Vectors and everything else >> > > >>> - Stretch goal: Global vectors indexing support (like IVF family >> of >> > > >>> algorithms) >> > > >>> - First party MCP support >> > > >>> >> > > >>> ** General* >> > > >>> - Official client libraries in Python, Rust, Go, etc. >> > > >>> - Something akin to Kibana / OpenSearch dashboards >> > > >>> - A new modern UI with feature completeness >> > > >>> - Entries in every meaningful AI leaderboard out there, >> preferably at >> > > par >> > > >>> with other Lucene based search engines >> > > >>> - Tons of more examples and live demos >> > > >>> >> > > >>> >> > > >>> ** User experience *- Fix naming everywhere (if you know Solr, >> you know >> > > >>> what I mean) >> > > >>> - No confusion around various modes of Solr >> > > >>> - Clear documentation of the API >> > > >>> >> > > >>> We may be able to achieve these, or we might not be able to. If >> we work >> > > >>> towards these goals (or some of these), these should be >> achievable. We >> > > >> will >> > > >>> be in an excellent position with regard to earning back respect >> among >> > > the >> > > >>> community and placing it at par or above search and AI engines. >> Solr 10 >> > > >> is >> > > >>> a great time to hit these goals. >> > > >>> >> > > >>> If someone has ideas (no matter how crazy, hard, or exploratory) >> on >> > > what >> > > >>> else could be good to have, please help us with suggestions. >> > > >>> >> >> >> Making zookeeper optional would go a long way for user goodwill and >> adoption. >> > > > -- > 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)
