Hey everyone,
We are getting close to closing out all of the issues currently marked for
the v0.5.0 Solr Operator release. We want to get this release out as soon
as possible, in order to support v1.22 Kubernetes clusters.
Here is a link to the milestone, which shows that all but one (possibly
un
Agree. Solr too often suffers from “not invented here” syndrome.
OpenAPI is closer to REST, , i.e. using the http DELETE verb for deleting
resources etc. I think the only selling-point for v2 was that it allows mixing
lots of actions like adding and deleting in the same atomic request. But if
d
I'm definitely +1 on the OpenAPI requirement for v2 going forward.
On Fri, Oct 29, 2021 at 12:04 PM Timothy Potter
wrote:
> I actually think that should be a hard requirement for the "next" API
> ... if v2 is so different and awkward compared to a broadly adopted
> standard, I'd say that's a sho
I actually think that should be a hard requirement for the "next" API
... if v2 is so different and awkward compared to a broadly adopted
standard, I'd say that's a short-coming of the v2 design. If we're
going to keep rolling out APIs that no standardized tooling supports,
just stick with v1, our
I did try to write a OpenAPI specification for V2, and discovered how much
customization/specifics I would have to do, and gave up because we were so very
different. With the “experimental” tag, we could evolve towards the OpenAPI
spec standards if folks wanted to ;-)
> On Oct 29, 2021, at 11
Does the v2 API support OpenAPI? I looked over the docs and it seems
like not, which is a shame. OpenAPI
(https://swagger.io/specification/) opens up a mature ecosystem of
tooling. The _introspection endpoint seems nice but if automated tools
can't understand it, then our users can't auto-generate
edit:
6. (+Gus) Providing be evidenced by a the node *adding itself to a list* of
ephemeral nodes (similar to live_nodes) for each role
On Fri, Oct 29, 2021 at 9:40 AM Gus Heck wrote:
> I've heard a number of folks agree that we should not have negative (role
> removal) values for roles (!data i
I've heard a number of folks agree that we should not have negative (role
removal) values for roles (!data in the sip).
I also don't like the idea of the "coordinator" creating assumptions about
other roles. I think the point of avoiding "!data" is to make it
programmatically and logically easy to
> Improved cluster stability. Restarting the leader is far simpler than
> electing a new leader, peer syncing, index finger printing etc
(I'll assume a single TLOG replica on its own pod as I think Joel
suggested in his latest reply.)
Restarts are definitely simpler than leader-election, but I'
Kube may have solutions to your questions. It's mainly about carefully
constructing collections. One approach would be to place each tlog leader
in it's own pod and using node anti-affinitity rules to spread them across
kubernetes nodes and availability zones. We're currently working on a Solr
coll
> I'll introduce a change to the SIP document, unless there are
objections/questions/concerns. WDYT?
I've made the change to the document. Feedback on this welcome.
On Fri, Oct 29, 2021 at 2:52 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> It seems to me, after going through this
It seems to me, after going through this thread, that the role "query" is
misleading for what we're planning to introduce in SOLR-15715. We're
essentially introducing a functionality for performing, what we initially
called, "query aggregations". The actual queries run on data nodes anyway,
just th
If we make collections role-aware for example (replicas of that collection
can only be placed on nodes with a specific role, in addition to the other
role based constraints), the set of roles should be user extensible and not
fixed.
If collections are not role aware, the constraints introduced by
13 matches
Mail list logo
