Right. Ping is core (and collection, I hope) specific. It assumes a fairly static scenario.
On Tue, Jun 27, 2023 at 7:20 PM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > Thanks for chiming in Mikhail! > > > Then, ping has that healthcheckFile feature which lets one turn a node > off from the pool > > You mean turn a "core" off, right? Not an entire node, unless I'm > missing something? If this was a hidden LB API we could use to cordon > particular nodes prior to restart, etc, I'd be all for keeping it. > But AFAICT the healthcheck file that gets created is put inside of the > specified core's data directory, so it only affects traffic to that > specified core. (And of course, to take advantage of that at all > users would need to have some sort of core-aware proxy/LB.) > > I absolutely agree though that it'd be really nice if Solr had some > sort of node-level cordoning API. I swear I read something about that > in a recent SIP, but can't find a pointer at the moment... > > Jason > > > On Mon, Jun 26, 2023 at 3:31 PM Mikhail Khludnev <m...@apache.org> wrote: > > > > Hello Jason, > > I have to say my production experience is quite limited. > > Then, ping has that healthcheckFile feature which lets one turn a node > off > > from the pool via Solr app level. > > Nowadays, it should be done via LB API, but ping allows to organise a > > rolling recycle via primitive bash script. > > > > Please don't consider it as an opinion, it's just a reminder. My vote > is: 0 > > > > On Mon, Jun 26, 2023 at 9:57 PM Jason Gerlowski <gerlowsk...@gmail.com> > > wrote: > > > > > Hey all, > > > > > > Is Solr's "ping" API still useful for folks today? > > > > > > "/admin/ping" was initially designed as a healthcheck for individual > > > SolrCore instances. The idea was that it could be checked > > > periodically by an external loadbalancer (that, presumably, was aware > > > not just of Solr nodes but of the topology of cores across the > > > cluster). > > > > > > This made sense in 2012 when /admin/ping was introduced, but I'm not > > > so sure it still does today. > > > > > > AFAICT, over time Solr usage has come to prefer node-level > > > healthchecks, and other APIs have sprung up to meet that need. (e.g. > > > the /admin/info/system and /admin/info/health endpoints commonly used > > > as liveness/readiness probes in Kubernetes environments). > > > > > > Even SolrJ's "load-balancing" client (used by both cloud and > > > "standalone" deployments) relies on node-level checks. And of course > > > the advent and prevalence of SolrCloud have even further reduced the > > > need to track per-core health outside of Solr/ZK. > > > > > > Does /admin/ping still have usecases that can't be met by other APIs? > > > Or should we consider deprecating and removing it in 10.0? > > > > > > Best, > > > > > > Jason > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > > > > -- > > Sincerely yours > > Mikhail Khludnev > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > -- Sincerely yours Mikhail Khludnev
