ConfigSetService is pluggable, and this works!(*) At Salesforce, we
use FileSystemConfigSetService with SolrCloud. Well actually a hybrid
thing that we could open-source but we have yet needed it actually, as
the only ConfigSet we use is immutable in our docker image.
(*) there is a feature or t
I'm not sure this was help up by arguments. The first part that I tried to
tackle was the Kubernetes Config Set management, and that turned into an
absolute beast.
Apparently, a ton of our configSet code relies on the fact that configSets
live in Zookeeper (even though there is an interface...) if
We need a complete path for scaling from the smallest Solr set ups to the
largest that is well supported by the community, and this seems to be key to
supporting the largest deployments. So this make sense to me.
Would saying that this kind of change is targeting Solr 10 take some of the
pres
I think of this from time to time. To get some progress, should be first agree
in this thread that it is a decent idea, and that a new Solr module is
warranted for this?
I'd hate to see good initatives like this to he held up by arguments not
related to the code itself but to the lifecycle or w
Yeah good question. Everything would be included in a single “kubernetes”
module. So while everything can be done independently, the first feature
will have to create the module, then the others features can be added.
Luckily adding a module is pretty straightforward, so it doesnt matter
which fea
Hello,
Sorry for being late to the party. The SIP sounds good to me.
Houston, you already mentioned that work for the module is easy to
break down. You're referring to the fact that pretty much every major
piece of functionality (Authentication, ConfigSets...) can be
developed almost independent
Hello team,
noob warning:
today I learned what SIP means. with SIP17 and 18 being very interesting
reads.
https://cwiki.apache.org/confluence/display/SOLR/Solr+Improvement+Proposals
Too many telephone references.
sorry for the interruption.
Alejandro Arrieta
On Thu, Apr 20, 2023 at 5:27 PM Housto
Thanks for the questions Jason!
So the general idea is that we'd add a Solr contrib/module, and that
> module would have a dep on some sort of Kubernetes client so it could
> manage certain Solr entities (e.g. security.json, configsets, etc.) as
> Kubernetes resources (configmaps, etc.). Am I und
Hi Houston,
So the general idea is that we'd add a Solr contrib/module, and that
module would have a dep on some sort of Kubernetes client so it could
manage certain Solr entities (e.g. security.json, configsets, etc.) as
Kubernetes resources (configmaps, etc.). Am I understanding that
right?
>
Hey everyone,
This is a new SIP, not a duplicate of SIP-17 (Authoscaling on Kubernetes),
and completely unrelated.
Basically there is a lot of very messy logic we do in the Solr Operator to
bootstrap security and manage various things. This logic must exist because
Solr has no idea that Kubernete
10 matches
Mail list logo
