+1 to Alex's sentiment. I like the analogy with the DIH.
A warning/notice for bin/post is fine. Maybe something like:
> This tool exists to help beginning Solr users and for rapid prototyping.
It may work fine in some "production" scenarios but you should probably use
something else like Curl,
I think in previous discussions * schema (all text or all string) was
advanced as a likely replacement for schemaless. It won't bother newbies
with any errors aside from duplicate id's and be 100% predictable.
Adjustments to schema from there would all be "whatever the user needed"
and not foisting
It's been >72h since the vote was initiated and the result is:
+1 4 (4 binding)
0 0
-1 0
This vote has PASSED
On Wed, Apr 28, 2021 at 11:17 AM Jan Høydahl
wrote:
> Ok, I ran the commands and got the smoke tester to continue
>
> Successfully smoke tested the Solr Operator v0.3.0!
>
> Here'
It's been >72h since the vote was initiated and the result is:
+1 4 (4 binding)
0 0
-1 0
This vote has PASSED
There is some black magic in schemaless for sure. An interesting thing
about it though ... it's not just doing field guessing and dynamic
schema mutation, it's also doing some field name normalization
(removing whitespace), ID injection (if needed), and locale-aware
parsing of incoming data (which
I agree with Alex here. We can't overload beginners with a bunch of
jargon and complexity just because experts understand how to use curl
effectively. I also don't think we should remove a feature b/c one
instance of misuse is found in the wild, sounds like Gus' client was
being lazy. Better docs a
Beginners should experience as little black magic as possible. Post tool is
black magic. Schemaless is black magic. I feel we should remove both.
On Thu, 29 Apr, 2021, 2:56 am Alexandre Rafalovitch,
wrote:
> "Good enough/Recommended" for what? Serious question.
>
> Because it may be - more than
"Good enough/Recommended" for what? Serious question.
Because it may be - more than - good enough to "send files to the
server", but the post tool is also doing a lot of Solr business logic
that beginner users may not have understood yet. Like automatic
commit. Like choosing endpoint and content t
We should remove the post tool
Altogether. Curl is good enough and recommended.
On Thu, 29 Apr, 2021, 2:15 am Gus Heck, wrote:
> I've generally been of the impression/opinion that the Post Tool is really
> just a convenience for folks testing out solr to see what it can do, and
> not really mean
I've generally been of the impression/opinion that the Post Tool is really
just a convenience for folks testing out solr to see what it can do, and
not really meant as a production ingestion solution.
A little while back I had a client that had a third party tool that
"integrated with solr" by inv
> Will we deprecate v1 APIs? When?
I would love to see the v2 APIs get to a point where we can deprecate
v1 for eventual removal. But I don't think we're there yet. Eric
Pugh, myself, and some others have made recent progress, but there are
still some pretty big gaps that stop v2 from being a vi
Absent anything else, I want us to stop breaking whenever Lucene makes
an incompatible change reflected in a snapshot. Pinning to a 9.0
release of theirs would give us that. Everything else is gravy.
9.0 will be built with Gradle, built after the split, there's already
a lot going into it. The way
(binding)
Logo vote: L4, L-1
Icon vote: I-4
On Tue, Apr 27, 2021 at 8:34 PM Gus Heck wrote:
>
> (binding)
> L-2 L-1 L-3
> I-3 I-2 I-1
>
> On Tue, Apr 27, 2021 at 5:00 PM Houston Putman wrote:
>>
>> Hello Solr users & devs,
>>
>> The Solr Operator is the first subproject under Apache Solr and
On v2 API,
I did some review a while ago, though the goal was to compare its
coverage with solrconfig.xml, rather than with V1.
My discoveries (umbrella and children) are in SOLR-14795 .
Regards,
Alex.
On Wed, 28 Apr 2021 at 12:04, Jan Høydahl wrote:
>
> Hi all,
>
> We've come a long way si
Ok, I ran the commands and got the smoke tester to continue
Successfully smoke tested the Solr Operator v0.3.0!
Here's my +1 (only ran smoke tester)
Jan
> 28. apr. 2021 kl. 17:56 skrev Anshum Gupta :
>
> +1 (binding)
>
> Successfully smoke tested the Solr Operator v0.3.0!
>
> and thank you,
I am presently working on getting some lucene changes backported into 8.9
to support the AQP (SIP-9), which I'd like to finally get resolved for 8.9,
I'm prioritizing that because that means that in theory at least Lucene 8.9
is not held up, though I guess we are still co-releasing for 8.x?
On Wed
Hi all,
We've come a long way since I last looked at the Roadmap WIKI page at
https://cwiki.apache.org/confluence/display/SOLR/Roadmap
We have setup the Solr TLP, released a few new versions and landed some of the
major features for 9.0
Now is probably a good time to do some forward-thinking,
+1 (binding)
Successfully smoke tested the Solr Operator v0.3.0!
and thank you, Houston for the patience.
On Fri, Apr 23, 2021 at 3:43 PM Houston Putman wrote:
> Please vote for release candidate 3 for the Solr Operator v0.3.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.
That's possible. It does break some tests but most important will likely
not cover all cases (node up during the massive ZK update).
Le mer. 28 avr. 2021 à 11:08, Jan Høydahl a
écrit :
> Could the Overseer do a simple live_nodes check before executing the
> DOWNNODE message? If the node has a mo
Could the Overseer do a simple live_nodes check before executing the DOWNNODE
message? If the node has a more recent entry in live_nodes than the DOWNODE msg
then drop it? Not sure if this is at all possible?
Jan
> 28. apr. 2021 kl. 10:18 skrev Ilan Ginzburg :
>
> When a SolrCloud node goes do
When a SolrCloud node goes down and back up in relatively rapid sequence
(not unusual in Public Cloud environments), it appears possible that the
DOWNNODE cluster state change message gets processed (or completes
processing) after the node has restarted.
This delayed execution will then mark repl
21 matches
Mail list logo
