----- 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
