I do not deny that a standardized framework may be helpful. I'm already
suffering from the PTSD of restlet integration. The integration code was
extremely complex and a security nightmare.It was added without any perf
tests too. It took many years to get rid of that
On Fri, Dec 3, 2021 at 1:37 A
Negative roles have a place
Example is overseer
There are 3 possible choices for that role
a) preferred: always be in front of the election queue
b) on: not preferred, but can be an overseer if no preferred overseer nodes
are available
c) off: never become an overseer
Today we only have options
Negative roles add a lot of complexity, I would really want to stay away
from them. That’s why I want strict roles up front. It’s maybe ok to push
this decision out, but it also seems like the sort of thing we should
consider at the start.
On Thu, Dec 2, 2021 at 5:52 PM Noble Paul wrote:
> Yes.
Hi, I had a quick look and it seems that Anna is right, but there should be
a case where you ask to rerank more documents than what you want to see..
need to review the code :)
cheers,
Diego
On Thu, 2 Dec 2021, 16:40 Alessandro Benedetti,
wrote:
> Adding Christine and Diego to the loop if th
Yes. Negative roles is not a bad idea. If I start a node for
machine learning purposes, I wouldn't want that node to ever participate in
overseer election
On Fri, Dec 3, 2021, 6:50 AM Ilan Ginzburg wrote:
> If we have non strict roles (like overseer), then it does make sense
> to have negative r
If we have non strict roles (like overseer), then it does make sense
to have negative roles.
That way I can define which are the two nodes that I'd prefer the
overseer to run on, and a few other nodes on which it should
definitely never run for various reasons. And in case these
"!overseer" are the
Adding Christine and Diego to the loop if they missed this.
Thanks Anna for raising.
Cheers
--
Alessandro Benedetti
Apache Lucene/Solr Committer
Director, R&D Software Engineer, Search Consultant
www.sease.io
On Wed, 10 Nov 2021 at 16:41, Anna Ruggero wrote:
> Hi all,
>
> With the Strict/Loose option and sensible defaults, users cannot trip
>> themselves up by default, but the option is there for people to tinker and
>> have an iron grip over their cluster.
>>
>
> +1 to sensible defaults so users don't trip themselves. The option to
> tinker for tighter grip can
> 99% of Solr users never see the java code that implements an API let alone
> writing a new API.
We may be talking past each other here a bit Noble. The JAX-RS
benefits I've been trying to describe are to benefit us developers,
not Solr users. I agree that 99% of our users won't know or care
a
Agree, Ishan.
Let's welcome and cheer initiatives to modernize this old codebase.
Diving in deep and un-tangling DispatchFilter like Gus is attempting is brave.
And testing JAX-RS to modernize APIs and make the codebas easier to grok is
also not for the faint hearted.
I hope both initiatives end
10 matches
Mail list logo
