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)
