Open Stack

----- Original Message -----
> On Tue, 2014-04-08 at 10:49 +0000, Day, Phil wrote:
> > On a large cloud you’re protect against this to some extent if the
> > number of servers is >> number of instances in the quota.
> > 
> > However it does feel that there are a couple of things missing to
> > really provide some better protection:
> > 
> > -         A quota value on the maximum size of a server group
> > -         A policy setting so that the ability to use service-groups
> > can be controlled on a per project basis
> 
> Alternately, we could just have the affinity filters serve as weighting
> filters instead of returning NoValidHosts.
> 
> That way, a request containing an affinity hint would cause the
> scheduler to prefer placing the new VM near (or not-near) other
> instances in the server group, but if no hosts exist that meet that
> criteria, the filter simply finds a host with the most (or fewest, in
> case of anti-affinity) instances that meet the affinity criteria.
> 
> Best,
> -jay

This is often called "soft" affinity/anti-affinity (though admittedly typically in the context of CPU affinity), I had been independently mulling whether this would make sense as an additional policy for server groups. That said although it's a simple solution for the problem noted in this thread I don't think it's desirable to do this in as a replacement for the existing support and remove any ability to have "hard" affinity/anti-affinity - other.

Some users actually expect/demand an error if the affinity or anti-affinity requirements of the workload can't be met, perhaps this is a case where sensible default tunables are required and the operators that want/need to provide "hard" affinity/anti-affinity need to explicitly enable it?

-Steve