Open Stack

On 10/07/2015 07:23 PM, Ian Wells wrote:
> On 7 October 2015 at 16:00, Chris Friesen <chris.friesen at windriver.com
> <mailto:chris.friesen at windriver.com>> wrote:
>
>     1) Some resources (RAM) only require tracking amounts.  Other resources
>     (CPUs, PCI devices) require tracking allocation of specific individual host
>     resources (for CPU pinning, PCI device allocation, etc.).  Presumably for
>     the latter we would have to actually do the allocation of resources at the
>     time of the scheduling operation in order to update the database with the
>     claimed resources in a race-free way.
>
>
> The whole process is inherently racy (and this is inevitable, and correct),
> which is why the scheduler works the way it does:
>
> - scheduler guesses at a host based on (guaranteed - hello distributed systems!)
> outdated information
> - VM is scheduled to a host that looks like it might work, and host attempts to
> run it
> - VM run may fail (because the information was outdated or has become outdated),
> in which case we retry the schedule

Why is it inevitable?

Theoretically if the DB knew about what resources were originally available and 
what resources have been consumed, then it should be able to allocate resources 
race-free (possibly with some retries involved if racing against other 
schedulers updating the DB, but that would be internal to the scheduler itself).

Or does that just not scale enough and we need to use inherently racy models?

Chris