Comment 26 for bug 1341420

Given the discussion around this in the scheduler meeting, moving this to a whishlist item.

Much of the behaviour here is as designed, and the retry loop should minimise the affects seen by API users. The caching_scheduler also helps for cases where you only run one scheduler, reducing the races even further, in most cases. The randomisation weigher also helps with that, somewhat.

The issue tends to be very deployment specific, and certainly the current scheduler is optimised for when the cloud generally has some free space, and gets expanded before it becomes full. Which was considered the typical cloud use case, at the time the scheduler was written.