Re: Should v2 API be "experimental"

2021-11-04 Thread Shawn Heisey
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

Re: First class support for node roles

2021-11-04 Thread Shawn Heisey
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

Re: Should v2 API be "experimental"

2021-11-04 Thread Gus Heck
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

Re: First class support for node roles

2021-11-04 Thread Noble Paul
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

Re: First class support for node roles

2021-11-04 Thread Noble Paul
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

Re: Should v2 API be "experimental"

2021-11-04 Thread Jason Gerlowski
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

Re: 8.11 release candidate

2021-11-04 Thread Adrien Grand
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

Re: First class support for node roles

2021-11-04 Thread Gus Heck
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

Re: First class support for node roles

2021-11-04 Thread Timothy Potter
+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

Re: First class support for node roles

2021-11-04 Thread Ilan Ginzburg
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

Re: 8.11 release candidate

2021-11-04 Thread Jan Høydahl
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: >

Re: SplitShard Bug in Solr 8.4.1

2021-11-04 Thread David Smiley
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

Re: Solr Docker CI Integration - Nightly builds

2021-11-04 Thread Eric Pugh
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

Re: Copy Field Enhancements

2021-11-04 Thread David Smiley
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

Re: First class support for node roles

2021-11-04 Thread Noble Paul
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

Re: First class support for node roles

2021-11-04 Thread Ilan Ginzburg
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

Re: First class support for node roles

2021-11-04 Thread Noble Paul
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

Re: First class support for node roles

2021-11-04 Thread Ishan Chattopadhyaya
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

Re: 8.11 release candidate

2021-11-04 Thread Adrien Grand
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

Re: First class support for node roles

2021-11-04 Thread Jan Høydahl
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