This discussion is relevant to a conundrum I face, touching
HealthCheckRequest. It has a little hack to detect it's being used with
CloudSolrClient so it can induce a failure because it's not supposed to be
used in a node-ambiguous way; it's supposed to be directed at a specific
node to have meani
Hey Christos,
Sorry again for the delay; some replies inline.
> For '/api/node' how can I tell which node I am interacting with when
> running in cloud mode? Am I connecting to a specific node via a different
> hostname + port, or am I connecting with a node through a load balancer /
> zookeeper?
>
> '/api/node' is reserved for APIs that only impact the receiving node
> (and aren't otherwise proxied or distributed)
That makes sense to me. In my suggestions before I try to eliminate the
difference between the two modes, standalone and cloud, at API level, so
that clients always interact th
Hey Christos,
Thanks for raising this!
> without having worked on the API before and without participating in any
> prior discussions
Quick summary of past discussions and decisions - not defending them
necessarily, but important context:
'/api/node' is reserved for APIs that only impact the r
Hello everyone,
I am looking into the v2 API and I was wondering what our final design will
look like in terms of single- and multi-node setups.
The main question I am trying to answer for myself is "Do we need to
distinguish between the operation mode at API endpoints"?
>From what I can see in