HoustonPutman commented on PR #1577:
URL: https://github.com/apache/solr/pull/1577#issuecomment-1516879031

   > 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)
   
   Yep 👍 
   
   > 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.
   
   Yes, but have the requirement be configurable. So anti-affinity could have a 
parameter "maxAffinity" (awful name, we would need a better one), which is a 
rule that "the maximum replicas in this affinityGroup is `<maxAffinity>`". 
   
   > 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.
   
   If we have both of these options available (anti-affinity and spread), I can 
imagine that they might be used with the different affinityGroup "keys". Like 
you would have spread setup for "availabilityZone" and anti-affinity setup for 
"rack".  In that case, you want to spread the nodes across availabilityZones as 
best as possible, and you want to avoid putting two replicas on the same rack.
   
   Thinking about it more given my answer above, I guess this does make more 
sense as a single option, with separate toggles like "maxSkew" and 
"maxAffinity" (still and awful name). And maybe we eventually allow for two of 
these to be configured.
   
   So in my example you would have the `spread` configured for both 
`availabilityZone` and `rack`. `availabilityZone` could have a `maxAffinity` of 
`-1` or `0`, meaning there is no issue with there being tons of replicas in 
that `availabilityZone`. But `rack` would have a `maxAffinity` of `2`, saying 
you don't want more than 2 replicas in a single `rack`. 
   
   I know that having multiple `affinityKeys` specified is not yet supported, 
just kind of thinking out loud. So in the end, I do think it makes sense to 
keep both features using the same system property, just in the future allow for 
defining multiple of them.
   
   


-- 
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

Reply via email to