[openstack-dev] [nova] question about e41fb84 "fix anti-affinity race condition on boot"
chris.friesen at windriver.com
Mon Mar 17 23:36:08 UTC 2014
On 03/17/2014 05:01 PM, Sylvain Bauza wrote:
> There are 2 distinct cases :
> 1. there are multiple schedulers involved in the decision
> 2. there is one single scheduler but there is a race condition on it
> About 1., I agree we need to see how the scheduler (and later on Gantt)
> could address decision-making based on distributed engines. At least, I
> consider the no-db scheduler blueprint responsible for using memcache
> instead of a relational DB could help some of these issues, as memcached
> can be distributed efficiently.
With a central database we could do a single atomic transaction that
looks something like "select the first host A from list of hosts L that
is not in the list of hosts used by servers in group G and then set the
host field for server S to A". In that context simultaneous updates
can't happen because they're serialized by the central database.
How would one handle the above for simultaneous scheduling operations
without a centralized data store? (I've never played with memcached, so
I'm not really familiar with what it can do.)
> About 2., that's a concurrency issue which can be addressed thanks to
> common practices for synchronizing actions. IMHO, a local lock can be
> enough for ensuring isolation
It's not that simple though. Currently the scheduler makes a decision,
but the results of that decision aren't actually kept in the scheduler
or written back to the db until much later when the instance is actually
spawned on the compute node. So when the next scheduler request comes
in we violate the scheduling policy. Local locking wouldn't help this.
More information about the OpenStack-dev