Comment 12 for bug 1341420

I personally dislike any change in the scheduler where it would wait for the end of booting an instance.
That would generate a locking mechanism in the scheduler while we currently have a chance to get one lock-free.

Scheduler is doing decisions based on its internal representation. If the representation is not up-to-date, there are big chances that eventually the request will fail but in that case, that's the role of formerly the compute node (and now the conductor) to issue a retry. Yes, that's by design that the scheduler can generate race conditions, but that also allows us to have an external scheduler without being necessary to remove the bits of locking mechanism.

Long story short, we have to find out how to improve the retry mechanism in the conductor, not in the scheduler.