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