Open Stack

On 04/08/2014 07:25 AM, Jay Pipes wrote:
> 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.

I'd be in favor of this.   I've actually been playing with an internal 
patch to do both of these things, though in my case I was just doing it 
via metadata on the group and a couple hacks in the scheduler and the 
compute node.

Basically I added a group_size metadata field and a "best_effort" flag 
to indicate whether we should error out or continue on if the policy 
can't be properly met.

Currently mine just falls back to the regular scheduler if it can't meet 
the policy, but I had been thinking about what it would take to do it 
like you suggest above, where we try to abide by the spirit of the 
policy even if we can't quite satisfy the letter of it.

Chris