tflobbe commented on PR #1577: URL: https://github.com/apache/solr/pull/1577#issuecomment-1516808584
> I do think a different name would be more appropriate though. I see. I wasn't aware of the "spread" feature in Kubernetes, but yes, it does look closer to what I have here. I was actually going with this naming based on Kubernetes' use of affinity/anti-affinity and making this a "soft" anti-affinity, and I was initially thinking about giving up on the rule if it couldn't be satisfied, but ended up implementing a logic similar to the "spread" in such case. > Also I completely support adding both of these features, there should be both a spread and an anti_affinity. If I understand correctly, you are suggesting: * Let users configure the "spread", which is exactly what the PR is doing for now (new features such as the `maxSkew` could be added in the future) * Make anti-affinity always "required" when configured: Attempt to spread the replicas, but fail if more than one replica is placed on the same affinity group. It probably makes sense to keep both features using the same system property for defining the affinity groups (or "domains"?), right? I see no reason to have both features enabled but using different labels. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
