Hi,
To achieve the below requirement, thought to use "Shingle filter". Can you
please correct if I am wrong.
User input: solr query analysis
Results : (in same order) - exact match at top following by partial match then
by individual words
Solr query analysis is the best practice
solr query
> >> Agree. However, I disagree with ideas where "query analysis" has a role
> of its own. Where would that lead us to? Separate roles for
>
>> nodes that do "faceting" or "spell correction" etc.? But anyway, that is
> for discussion when we add future roles. This is beyond this SIP.
>
> I am not
So we need to balance first time startup vs while running concerns for
sure.
If they haven't read anything and just start up the way they always did,
they provide an external zk... no problem 100% back compat
If they want to start a set of nodes for the first time using embedded zk,
they should co
> Boiling it down the idea I'm proposing is that roles required for back
compatibility get explicitly added on startup, if not by the user then by
the code. This is more flexible than assuming that no role means every
role, because then every new feature that has a role will end up on legacy
cluste
Jan, +1 to using -Dsolr.node.roles instead of -Dnode.roles.
On Mon, Nov 1, 2021 at 10:18 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> > But I assume that a new feature in 9.x that introduces a new role can
> also decide for some alternative back-compat logic to support rolling
>
Very sorry don't mean to sound offended, Frustrated yes offended no :)...
the most difficult thing about communication is the illusion it has
occurred :)
If you read back just a few emails you'll see where I talk about roles
being applied on startup. Boiling it down the idea I'm proposing is that
> But I assume that a new feature in 9.x that introduces a new role can
also decide for some alternative back-compat logic to support rolling
restart if it is needed.
IMHO, having per feature enable/disable flag would be ugly user experience.
Imagine, telling users that for the newly introduced "
> If you read more closely, my way can provide full back compatibility. To
say or imply it doesn't isn't helping. Perhaps you need to re-read?
I understand e-mails are frustrating, and I'm trying my best. Please don't
be offended, and kindly point me to the exact part you want me to re-read.
On M
Anything can be avoided. The question is what is the long term cost for all
users, and all contributors in the future. I'd rather make the system clean
and easy to understand and easy to maintain vs this one special case of
re-designing your cluster on the fly during an outage.
On Mon, Nov 1, 2021
In this SIP, I'm mainly trying to introduce the broader concept of first
class roles and mechanism to assign roles to nodes. I'm then advocating
that the implementation of each role be left to decide how to use those
roles.
> Roles should never change without restart. 1-100 should not suddenly
bec
On Mon, Nov 1, 2021 at 12:22 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> >Positive - They denote the existence of a capability
>
> Agree, the SIP already reflects this.
>
> > Absolute - Absence/Presence binary identification of a capability; no
> implications, no assumption
> This person has not read the documentation we certainly will provide.
Docs would clearly state that the correct way to achieve this is
> Solr1-100: -Dnode.roles=data
> Solr101: -Dnode.roles=overseer
Yes, and that would need the user to restart all 100 nodes in the cluster.
Totally avoidable, es
On Mon, Nov 1, 2021 at 12:00 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> > Ilan: A node not having node.roles defined should be assumed to have all
> roles. Not only data. I don't see a reason to special case this one or any
> role.
> > Gus: There should be no "assumptions" Nothi
>Positive - They denote the existence of a capability
Agree, the SIP already reflects this.
> Absolute - Absence/Presence binary identification of a capability; no
implications, no assumptions
Disagree, we need backcompat handling on nodes running without any roles.
There has to be an impl
I think it is safe to assume that small clusters, say 1-5 nodes will most often
want to have all features on all nodes as the cluster is too small to
specialize, and then the default is perfect.
For large clusters we should recommend explicitly specifying roles during the
9.0 upgrade. So if you
> Ilan: A node not having node.roles defined should be assumed to have all
roles. Not only data. I don't see a reason to special case this one or any
role.
> Gus: There should be no "assumptions" Nothing to figure out. A node has a
role or not. For back compatibility reasons, all roles would be ass
On Mon, Nov 1, 2021 at 11:12 AM Jan Høydahl wrote:
>
>
> > 1. nov. 2021 kl. 14:46 skrev Ilan Ginzburg :
> > A node not having node.roles defined should be assumed to have all
> roles. Not only data. I don't see a reason to special case this one or any
> role.
>
> +1, make it simple and transparen
> If we make collections role-aware for example (replicas of that
collection can only be
> placed on nodes with a specific role, in addition to the other role based
constraints),
> the set of roles should be user extensible and not fixed.
> If collections are not role aware, the constraints introdu
> 1. nov. 2021 kl. 14:46 skrev Ilan Ginzburg :
> A node not having node.roles defined should be assumed to have all roles. Not
> only data. I don't see a reason to special case this one or any role.
+1, make it simple and transparent. No role == all roles. Explicit list of
roles = exactly tho
TLDR summary of what I'm advocating. I want node roles to be:
- Positive - They denote the existence of a capability
- Absolute - Absence/Presence binary identification of a capability; no
implications, no assumptions
- Focused - Do one thing per role
- Accessible - It should be dea
On Mon, Nov 1, 2021 at 9:47 AM Ilan Ginzburg wrote:
> On Mon, Nov 1, 2021 at 12:53 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> I've removed the concept of "!data" from the SIP proposal. A node that
>> doesn't have -Dnode.roles parameter will be assumed to have
>> -Dnode.rol
On Mon, Nov 1, 2021 at 7:53 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> Hi Gus,
>
> Thanks for the summary.
>
> > (+Gus, +Houston,+Ilan) Positive roles, the existence of which implies
> functionality such that if a node can provide functionality. i.e. it always
> has the role if
I don't know OpenAPI well enough to have an opinion on whether it's
right for Solr, except to say that if we do want OpenAPI then an
"experimental" designation sounds helpful for giving us flexibility to
change our APIs as necessary.
I recently created SOLR-15734 as an umbrella for tracking and
di
On Mon, Nov 1, 2021 at 12:53 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> I've removed the concept of "!data" from the SIP proposal. A node that
> doesn't have -Dnode.roles parameter will be assumed to have
> -Dnode.roles=data. If a node is started with a node.roles param, it must
> Similarly, the "overseer" role would limit the nodes that participate in
the Overseer election. The Overseer election
> code would have to remove (or not add) all non qualifying nodes from the
election, and we should expect a node
> without role "overseer" to refuse to start the Overseer machiner
If the changes and the scope seem acceptable, should we proceed for a vote?
On Mon, Nov 1, 2021 at 5:22 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> Hi Gus,
>
> Thanks for the summary.
>
> > (+Gus, +Houston,+Ilan) Positive roles, the existence of which implies
> functionality suc
Hi Gus,
Thanks for the summary.
> (+Gus, +Houston,+Ilan) Positive roles, the existence of which implies
functionality such that if a node can provide functionality. i.e. it always
has the role if it can and if it doesn't have the role it can't provide the
functionality.
I've removed the concept
27 matches
Mail list logo
