Re: Approach for a new Autoscaling framework

In my opinion we have to (and therefore will) ship at least a basic prod ready implementation on top of the API that does simple things (not sure about rack, but for example balance cores and disk size without co locating replicas of same shard on same node). Without such an implementation, I suspe

Re: Approach for a new Autoscaling framework

Important discussion indeed. I don’t have time to dive deep into the PR or make up my mind whether there is a simpler and more future proof way of designing these APIs. But I understand that autoscaling is a complex beast and it is important we get it right. One question regarding having to wri

Re: Approach for a new Autoscaling framework

I think this is a valid thing to discuss on the dev list, since this isn't just about code comments. It seems to me that Ilan wants to discuss the philosophy around how to design plugins and the interfaces in Solr which the plugins will talk to. This is broad and affects much more than just the Aut

Re: Approach for a new Autoscaling framework

I think we should move the discussion back to the PR because it has more context and inline comments are possible. Having this discussion in 4 places (jira, pr, slack and dev list is very hard to keep track of). On Thu, 23 Jul, 2020, 5:57 pm Ilan Ginzburg, wrote: > [I’m moving a discussion from

Approach for a new Autoscaling framework

[I’m moving a discussion from the PR for SOLR-14613 to the dev list for a wider audience. This is about replacing the now (in master) gone Autoscaling framework with a way for clients to write their