On 11/4/2021 4:42 PM, Shawn Heisey wrote:
This is possibly a pipe dream:
Most of us are probably already aware that the original API ignores
unknown parameters sent in with a request. Some of our users utilize
this for log parsing -- by including some custom parameter on the
request that So
>From first RC thread:
Tim was very kind and created an 8.11.0 RC1 Solr docker image that you can
test this out with:
thelabdude/apache-solr-dev:8.11.0-rc1
And I'll link the draft release notes in case anyone has comments on it:
https://cwiki.apache.org/confluence/display/SOLR/Solr+Operator+Relea
Please vote for release candidate 2 for the Solr Operator v0.5.0
The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.5.0-RC2-revef00f0a2b6c8e3a5542c88ea575423b6fe194ddc
You can run the full smoke tester, with instructions below.
However
Houston made a very valid comment back then on the placement plugin support
of environment variables (dropped as a consequence).
https://issues.apache.org/jira/browse/SOLR-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286680#comment-17286680
It cou
Created https://issues.apache.org/jira/browse/SOLR-15793
...I'm out of ideas of how to try and fix this.
: Date: Thu, 11 Nov 2021 10:19:18 -0700 (MST)
: From: Chris Hostetter
: To: dev@solr.apache.org
: Cc: bui...@solr.apache.org
: Subject: Re: [JENKINS] Solr » Solr-Check-main - Build # 1937 -
The result is:
+1 0 (0 binding)
0 0
-1 1
Reason for failing is too few binding votes.
This vote has FAILED
Fix and smoke test included in:
https://github.com/apache/solr-operator/pull/374
Will officially end vote.
On Thu, Nov 11, 2021 at 11:29 AM Houston Putman wrote:
> Actually let me be the first to vote this down.
>
> -1
>
> I found a bug where VolumeRepository backups are deleted before starting
Agreed!
I’ve noticed that in the Play Framework, you can configure everything via a
property based configuration file, however it makes it easy to override the
property file via another one, or via an ENV variables:
db.default.username="smui"
db.default.username=${?SMUI_DB_USER}
Which turns
+1 to a roundup of env and props across the board. I think SIP 11 is on the
track of something. But can be done independent of this.
Jan Høydahl
> 11. nov. 2021 kl. 17:44 skrev Gus Heck :
>
> I guess all I mean is that it shouldn't be only sysprops. Enabling sysprops,
> Env vars etc seems fin
This problem reproduces for me locally as well.
It doesn't seem to be related to any recent changes -- even checking out a
Git SHA from several weeks ago when 'gradle check' passed just fine now
enounters this jruby/gem failure -- making me suspect something in a
remote gem/dep that we fetch i
I guess all I mean is that it shouldn't be only sysprops. Enabling
sysprops, Env vars etc seems fine but we need to clearly document
precedence among any/all options. What is convenient varies from case to
case and in a perfect world what I'd like to see is full support across
each style (files, zk
Actually let me be the first to vote this down.
-1
I found a bug where VolumeRepository backups are deleted before starting
the next recurring backup, meaning that only 1 backup can be stored at any
given time.
Will submit a (one-line) fix and spin up a new RC later today. (And
hopefully have th
I agree with Jan, when thinking about making Solr as cloud friendly as
possible EnvVars and (to a lesser extent) sysProps are much preferable than
having a setting in the solr.xml.
This is because it's easier to customize EnvVars per-node, while
customizing a config file is much harder, as those te
13 matches
Mail list logo
