I’d also like solr.xml to go away if at all possible, at least in cloud mode.
Some important points (to me at least).
- having to hand-edit _anything_ is A Bad Thing in a large, distributed system
since you need:
— an infrastructure to automagically distribute whatever it is you’re editing
to
I also opened SOLR-14826 as the placeholder. I'm not fully sure of its
priority but at least Alexandre expressed an interest in fixing it for
Solr, thanks.
If there is someone who wants to take the ownership, please feel free to
join. I will leave it there until LUCENE-9499 is done anyway.
I still don’t see this as a reason to add it to the main repo. Maybe create
a new repo just for this helm chart?
Anyways, as David said, the third party plug-in repository will be perfect
for this.
On Thu, 3 Sep 2020 at 19:36, LEE Ween Jiann
wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hey there,
Everything can of course be hard coded. Isn’t solr.xml is a way to hardcode
config in a more flexible way that a Java class?
I hoped to have the config passed to the plugin be overridable via system
properties like solr.xml allows (free disk size thresholds, log vs. fail
when some constraints
Hi Lee, Atri,
I'd like to volunteer to maintaining Solr Helm charts in a public GitHub
repository outside of Apache, unless we want to do so as part of
Lucene-Solr or elsewhere in Apache.
Regards,
Ishan
On Thu, 3 Sep, 2020, 8:16 pm Atri Sharma, wrote:
> The CouchDB example is a good one -- it
Jumping in late, but I don’t see why the help chart needs to be a part of
the core repository.
Like the HDFS repository, why not just add a link to the existing
repository somewhere on the main website?
On Thu, 3 Sep 2020 at 19:29, LEE Ween Jiann
wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi
Is this a consensus between all the Apache projects? Is there a discussion
going on?
On Thu, 3 Sep 2020 at 19:43, LEE Ween Jiann
wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The ideal case would be to have Apache/charts with all the helm charts
> that are orphaned.
>
>
> If not I guess, we will
Hi both,
Is there any updates on this? The helm stable chart repo is now deprecated,
could we move the helm chart to the apache GitHub repo?
Cheers,
WJ
From: David Smiley
Reply to: "dev@lucene.apache.org"
Date: Monday, 3 February 2020 at 1:07 AM
To: Solr/Lucene Dev
Subject: Re: Migrate Solr
The CouchDB example is a good one -- it is not a part of the core repository.
It might be a wide audience, but I would start a discussion at
committ...@apache.org for this.
Atri
On Thu, Sep 3, 2020 at 8:05 PM LEE Ween Jiann
wrote:
>
> No, where and who would be the right place and person to
The ideal case would be to have Apache/charts with all the helm charts that are
orphaned.
If not I guess, we will just wait and see if anyone picks up those charts.
From: Atri Sharma
Reply to: "dev@lucene.apache.org"
Date: Thursday, 3 September 2020 at 10:08 PM
To: "dev@lucene.apache.org"
Hey there,
The thing is there will **not** be repository after Nov 13.
Please refer to this link which was previously posted,
https://github.com/helm/charts/blob/master/README.md#deprecation-timeline
Cheers,
WJ
From: Atri Sharma
Reply to: "dev@lucene.apache.org"
Date: Thursday, 3 September
I can see that some of these configurations should be moved to
clusterporps.json, I don’t believe this is the case for all of them. Some
are configurations that are targeting the local node (i.e sharedLib path),
some are needed before connecting to ZooKeeper (zk config). Configuration
of global
Hmmm, interesting point about deliberately changing one solr.xml for testing
purposes. To emulate that on a per-node basis you’d have to have something like
a “node props” associated with each node, which my instant reaction to is
“y”.
As far as API only, I’d assumed changes to
bq. Isn’t solr.xml is a way to hardcode config in a more flexible way that a
Java class?
Yes, and the problem word here is “flexible”. For a single-node system that
flexibility is desirable. Flexibility comes at the cost of complexity,
especially in the SolrCloud case. In this case, not so
Thanks Ishan,
I still don't think it covers the cases very well. The possibilities of how
that handler could be screwing up things are infinite (it could be
corrupting local cores, causing OOMs, it could be spawning infinite loops,
you name it). If the new handler requires initialization that
I'd suggest Apache Community Development as a potential place for such a
cross-project discussion:
http://community.apache.org
https://lists.apache.org/list.html?d...@community.apache.org
https://issues.apache.org/jira/projects/COMDEV
From: dev@lucene.apache.org At: 09/03/20 15:46:52To:
Hi Tomas,
This type of a problem can be solved using alternate strategies. Here's how
you can do so: register the updated version of the plugin in /healthcheck2
(while simultaneously the older version continues to work at /healthcheck).
Make sure it works. Once it does, update the /healthcheck
On Fri, 4 Sep, 2020, 12:05 am Erick Erickson,
wrote:
>
>
> I wish everyone would just use Solr the way I think about it ;)
>
https://twitter.com/ichattopadhyaya/status/1210868171814473728
> > On Sep 3, 2020, at 2:11 PM, Tomás Fernández Löbbe
> wrote:
> >
> > I can see that some of these
A1, A2, D (binding)
Kevin Risden
On Thu, Sep 3, 2020 at 4:44 PM jim ferenczi wrote:
> A1 (binding)
>
> Le jeu. 3 sept. 2020 à 07:09, Noble Paul a écrit :
>
>> A1, A2, D binding
>>
>> On Thu, Sep 3, 2020 at 7:22 AM Jason Gerlowski
>> wrote:
>> >
>> > A1, A2, D (binding)
>> >
>> > On Wed,
Hello Lucene/Solr folks,
During Lucene development CI is used for build and unit tests to gate
merges. The CI doesn't yet include any analysis tools though, but their
use has been discussed [1]. I fixed some issues flagged by Facebook's
Infer and was prompted to bring up the topic here [2].
Tomás,
Oof, thanks for the note on TOS. I fixed the link. The tool can be
configured and I'm happy to make things work better for your use case.
Muse is free for public repos and will remain free for open source
indefinitely. You can try it and remove it any time - github is in charge
of access
A1 (binding)
Le jeu. 3 sept. 2020 à 07:09, Noble Paul a écrit :
> A1, A2, D binding
>
> On Thu, Sep 3, 2020 at 7:22 AM Jason Gerlowski
> wrote:
> >
> > A1, A2, D (binding)
> >
> > On Wed, Sep 2, 2020 at 10:47 AM Michael McCandless
> > wrote:
> > >
> > > A2, A1, C5, D (binding)
> > >
> > >
Thanks Tom. I think this could be very useful as long as it can be
configurable. (The "terms of use here[1] link to "google.com", so I
couldn't check that, but they claim it's free for public repos, so...). We
could always try it and remove it if we don't like it? What do others think?
[1]
Sounds reasonable to me. I suggest that you try to find which people
worked specifically on the existing restriction at the time RTG came about
and ask them.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Aug 18, 2020 at 7:56 PM Erick
Thank you, thank you, thank you!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Wed, Aug 26, 2020 at 3:42 PM Alexandre Rafalovitch
wrote:
> Dear all,
>
> Based on the discussion in SOLR-14726, Slack, and in many other JIRA
> issues, I am
(binding)
vote: D, A1
(thanks Ryan for your thorough vote instructions & preparation)
The parent directory of Solr home is not special. Where Solr Home is (as
you know) configurable. It's default location is different too, since it's
in /var/solr for both the Docker & service install script.
~ David Smiley
Apache Lucene/Solr Search Developer
Sounds great to me! I'm really glad to hear it works with the PR workflow,
and only on the files touched in the PR.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Sep 3, 2020 at 8:03 PM Tom DuBuisson wrote:
> Tomás,
> Oof, thanks for the
Thanks Dawid for that fantastic explanation!
What's the path of the ".lock" file you refer to?
gradlew -p solr/solrj dependencies
I observe it has many named dependency trees; some quite large.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue,
It was just recently updated:
https://issues.apache.org/jira/browse/SOLR-14606
8.7 will use 4.1.50.Final. I just checked by using a local distribution
(cd solr; ant dist) on branch_8x and looking for the netty jar files
therein.
~ David Smiley
Apache Lucene/Solr Search Developer
It's tempting to accomplish two goals at once (tutorial & searchable ref
guide) but I think the realities of making a *good* searchable ref guide
may distract someone from learning as it tries to do both well. A
searchable ref-guide could very well be its own project that we point
people learning
I pushed a fix for these failures about solr.cmd having tabs on branch_8x.
On Thu, Sep 3, 2020 at 10:42 AM Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/4265/
> Java: 64bit/jdk-14.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC
A1, A2, D (binding)
On Thu, Sep 3, 2020 at 7:09 AM Noble Paul wrote:
> A1, A2, D binding
>
> On Thu, Sep 3, 2020 at 7:22 AM Jason Gerlowski
> wrote:
> >
> > A1, A2, D (binding)
> >
> > On Wed, Sep 2, 2020 at 10:47 AM Michael McCandless
> > wrote:
> > >
> > > A2, A1, C5, D (binding)
> > >
> >
Noble,
In order for *clusterpropos.json* to replace what's currently done with
*solr.xml*, we'd need to introduce a mechanism to make configuration
available out of the box (when Zookeeper is still empty). And if
*clusterpropos.json* is to be used in standalone mode, it also must live
somewhere
Let’s not do another magic overlay json file on top of xml with all the
confusion it creates.
+1 to stick with solr.xml for current and ongoing feature development and not
hold up development based on things that may or may not happen in the future.
Discussing removal of solr.xml is a typical
> to stick with solr.xml for current and ongoing feature development and not
> hold up development based on things that may or may not happen in the future.
Where did I say that? There are so many features built recently using
clusterprops.json. The least we can do is stop piling more into
36 matches
Mail list logo
