"ClusterSolrClient" is a fine name but we already have a fine name
that users are using. Waiting till 10.0 is depressing to me, particularly
because it seems unnecessary. Is there disagreement that the possibility
of some users having to change something is too much to ask in a major
version?
~
> We can only hypothesize _why_ a client is dependent in the first place ...
> Perhaps to tweak/tune advanced options, timeouts. Perhaps to instrument mTLS
> details
Another use-case to add to this list would be auth settings. I'm
struggling to come up with a concrete example this minute, but
+1
Smoke tester passes for me, as did some manual testing.
(Testing was mostly focused on local and GCS backups, with some
attention paid to general use.)
On Tue, Mar 15, 2022 at 4:49 PM Houston Putman wrote:
>
> Please vote for release candidate 2 for the Solr Operator v0.5.1
>
> The artifacts
I feel like CloudSolrClient doesn't imply anything about HTTP 1 or 2,
anything about Apache or Jetty (or java.net.http). If we have exposed those
internal details in some ways, then that is unfortunate and should be
addressed.
I personally never use CloudHttp2SolrClient because I kind of assumed t
