On 02/13/2013 03:59 PM, Nick Coghlan wrote:
Ray asked about possible approaches to testing scheduler race
conditions
for
http://gerrit.beaker-project.org/#/c/1718/
Here's my suggestion:
1. Set up 2 systems, A and B
2. Set up a pair of jobs, each containing a recipeset with a pair of
recipes targeting the respective systems (so we will have recipes 1A,
1B, 2A, 2B queued in that order)
3. Mark system A unavailable
4. Monkeypatch beakerd.schedule_queued_recipe with a version that, after
calling the regular version, marks system A as available, if recipe 1B
was just scheduled
/me explains this step to Ray offline...
To clarify, the reason this monkeypatching trick works is that the
monkeypatched function gets called for every queued recipe, so it lets
us keep track of where the scheduling loop in beakerd is up to in
processing the queue:
schedule_queued_recipe(1A) # A unavailable, 1A remains queued
schedule_queued_recipe(1B) # A marked available in separate session
schedule_queued_recipe(2A) # 2A should also remain queued
schedule_queued_recipe(2B)
The current bug (since we're not using nested sessions) is that
schedule_queued_recipe(2A) will claim system A, resulting in the
deadlock we're trying to fix.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (
http://beaker-project.org/)
PulpDist Development Lead (
http://pulpdist.readthedocs.org)