On 11/4/21 1:20 PM, Jason Gerlowski wrote:
With that in mind, I think the next steps here should probably be to:
1. decide what label or term we want to go with ("evolving"?
"experimental"? "beta"?), and
2. figure out what the best way to publicize change in policy.
For (1) my vote is probably
On 11/4/21 2:51 PM, Noble Paul wrote:
The SIP can be boiled down to the following
* *Tag a node with a label (role) using a system property*
** Use the placement plugin to whitelist/block list certain nodes*
** Publish the roles through an API*
In general, for Solr, do we like the idea of hav
I raised the point as a general concern but I'm quite willing to accept the
clear majority opinion. Definitely not anywhere near veto :)
On Thu, Nov 4, 2021 at 3:20 PM Jason Gerlowski
wrote:
> Alright, it seems like there's general agreement that we should
> designate v2's evolving nature in som
The SIP can be boiled down to the following
* *Tag a node with a label (role) using a system property*
** Use the placement plugin to whitelist/block list certain nodes*
** Publish the roles through an API*
That's it
If you wish to add a new role, use the same concept.
Period
On Fri, Nov 5, 20
Yes Ilan
The coordinator is the first compelling usecase. The roles is the UX and
it's a very simple piece. The real work is coming as a separate PR.
Roles can be achieved in a clumsy way today. It's unintuitive and we don't
want to make the user to jump through the hoops.
I'll open a PR and you
Alright, it seems like there's general agreement that we should
designate v2's evolving nature in some way, and that this should allow
us to break backcompat if necessary on v2 going forward. There were
at least 8 voices in favor with the only disagreement being Gus who
expressed concern on the ba
Thanks Jan!
On Thu, Nov 4, 2021 at 2:32 PM Jan Høydahl wrote:
> I added a PR https://github.com/apache/lucene-solr/pull/2603 for
> SOLR-14438, that I had in the workings. I think it will do...
>
> Jan
>
> 4. nov. 2021 kl. 10:34 skrev Adrien Grand :
>
> Joel recommended not treating SOLR-15762 as
So one of the reasons my response to this proposal was that I like the idea
of roles, but not some of the details of the sip, is that while a lot of
things "are possible today" I see this feature as imparting a coherent
organization to the availability of those features. Seems like it would be
more
+1 to what Ilan said, that was my main point all along as well ;-)
There is merit in using what's already there vs. introducing some new
concept that might be useful for future use cases, but for now is just
useful for the query coordinator concept.
Also, I don't like the pseudo-core / -collection
I was noting that the real value of the proposal (real value = being able
to do things that are currently impossible with Solr) was due to an
independent concept of a coordinator "core", and that if we had this
(currently does not exist in Solr but apparently you do have it on a fork),
we can achie
I added a PR https://github.com/apache/lucene-solr/pull/2603 for SOLR-14438,
that I had in the workings. I think it will do...
Jan
> 4. nov. 2021 kl. 10:34 skrev Adrien Grand :
>
> Joel recommended not treating SOLR-15762 as a blocker, so we are left with
> the following issues as blockers:
>
It's a little hard to follow what you're saying and I'm unsure how you came
to certain conclusions (e.g. that a doc was served from a particular
shard). You could try to find an existing bug report, and failing that
then maybe file a new one, being very clear on what operations were
performed and
Likewise! I got to try out Solr and Lucene 9 against the Querqy library
really quickly because of this.
> On Nov 3, 2021, at 5:00 PM, David Smiley wrote:
>
> I just tried it. It's so cool to finally have this at long-last! Thanks so
> much Houston.
>
> ~ David Smiley
> Apache Lucene/Sol
Nested/child documents in Solr has been an evolutionary process, and it
shows. If it were designed from the beginning, there would be first-class
support for this in the schema, perhaps by having fields grouped by some
notion of a document type, and then copyFields would be there as well.
It's nev
The placement part of roles feature may use placement plugin API .
The implementation is not what we're discussing here. We need a consistent
story for the user when it comes to roles. This discussion is about the UX
rather than the impl.
Most of our discussions are about how we should implemen
A lot of the value of this SIP relies on the pseudo-core thing (because
placing on specific nodes is achievable today, Overseer role already
exists). Roles as described without the coordinator concept are just
another way to do things already possible today (with a very minor update
on the Affinity
None of the design is dictated by the version in which we implement this.
The SIP is mostly about the "what", "why" and the UX
I don't have any affinity to any particular version. This is definitely
going to happen in 9.x. Even if it is built in 9.x we will have to build
and support all versions o
We are targeting this for 9x. However, it can't hurt anyone to also
backport to 8x (if there's enough time and interest). For large clusters,
the separation of data and querying can potentially be a game changer.
Compatability worries are not just for those who upgrade, but also about
defaults for
Joel recommended not treating SOLR-15762 as a blocker, so we are left with
the following issues as blockers:
- SOLR-15706, which should hopefully be addressed soon.
- SOLR-14438, which hasn't had activity for a long time. Is someone
looking into it? Can someone comment on whether it should actual
Let's do ourself a service and target 9.0 for roles. It's too late to plan new
features into 8.x.
I don't understand the urgency either. I can get that certain Solr users would
wish for such a feature "yesterday" but that cannot drive our decisions on what
version to target for features. When t
20 matches
Mail list logo