On 05/22/2017 01:55 PM, Jay Pipes wrote:
On 05/22/2017 03:53 PM, Jonathan Proulx wrote:
To be clear on my view of the whole proposal
most of my Rescheduling that I've seen and want are of type "A" where
claim exceeds resources. At least I think they are type "A" and not
"C" unknown.
The exact case is that I over subsribe RAM (1.5x) my users typically over
claim so this is OK (my worst case is a hypervisor using only 10% of
claimed RAM). But there are some hotspots where propertional
utilization is high so libvirt won't start more VMs becasue it really
doesn't have the memory.
If that's solved (or will be at the time reschedule goes away), teh
cases I've actually experienced would be solved.
The anit-affinity use cases are currently most important to be of the
affinity scheduling and I haven't (to my knowlege) seen collisions in
that direction. So I could live with that race becuase for me it is
uncommon (though I imagine for others where positive affinity is
important teh race may get lost mroe frequently)
Thanks for the feedback, Jon.
For the record, affinity really doesn't have much of a race condition at all.
It's really only anti-affinity that has much of a chance of last-minute
violation.
Don't they have the same race on instance boot? Two instances being started in
the same (initially empty) affinity group could be scheduled in parallel and end
up on different compute nodes.
Chris
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
