On 07/22/2013 12:51 PM, John Garbutt wrote: > On 22 July 2013 13:23, Boris Pavlovic <[email protected]> wrote: >> I see only one race condition. (in current solution we have the same >> situtaiton) >> Between request to compute node and data is updated in DB, we could use >> wrong state of compute node. >> By the way it is fixed by retry. > > This race turns out to be a big deal when there are bursts of VM.start > requests. > > I am currently thinking about ways we can look to eliminate this one. > Hoping to have a design summit session on that.
Cool. In addition to retries, it's somewhat mitigated by using the scheduler_host_subset_size to reduce the chance that multiple schedulers choose the same host. # New instances will be scheduled on a host chosen randomly # from a subset of the N best hosts. This property defines the # subset size that a host is chosen from. A value of 1 chooses # the first host returned by the weighing functions. This # value must be at least 1. Any value less than 1 will be # ignored, and 1 will be used instead (integer value) #scheduler_host_subset_size=1 -- Russell Bryant _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
