Open Stack

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