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.
Chris _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
