Francois Gouget : testbot/lib: Make sure we have a consistent view of the VMs Status, no matter which Task we get the corresponding object from.
Alexandre Julliard
julliard at winehq.org
Tue May 6 12:32:38 CDT 2014
Module: tools
Branch: master
Commit: ad5dc5add5223edefd45ab693d238be5208b1c74
URL: http://source.winehq.org/git/tools.git/?a=commit;h=ad5dc5add5223edefd45ab693d238be5208b1c74
Author: Francois Gouget <fgouget at codeweavers.com>
Date: Tue May 6 12:40:49 2014 +0200
testbot/lib: Make sure we have a consistent view of the VMs Status, no matter which Task we get the corresponding object from.
This ensures we don't schedule two tasks on the same VM when there is more than one VM host.
Specifically, in the single VM host scenario the scheduler actions go
like this:
Schedule Jobs on Host1
Load Job1 from database
Load Step1 from database
Load Task1 from database
Load VM1 (e.g. buildvm) from database
VM1 is idle -> start Task1
VM1->Status = running
Save VM1 to the database
Load Job2 from database
Load Step2 from database
Load Task2 from database
Load VM2 (e.g. the same buildvm) from database
-> VM2->Status is up to date
VM2->Status is running -> nothing to do
All done
But in the two (or more) VM hosts scenario the first pass is when all
the objects are being loaded from database, while the second one just
reuses the already created Collections and Items. So in some cases
scheduling goes like this:
Schedule Jobs on Host1
Load Job1 from database
Load Step1 from database
Load Task1 from database
Load VM1 (e.g. buildvm) from database
VM1 is not on Host1 so continue
Load Job2 from database
Load Step2 from database
Load Task2 from database
Load VM2 (e.g. the same buildvm) from database
VM2 is not on Host1 so continue
Schedule Jobs on Host2
Job1 is already in memory
Step1 is already in memory
Task1 is already in memory
VM1 is already in memory
VM1 is idle -> start Task1
VM1->Status = running
Save VM1 to the database
Job2 is already in memory
Step2 is already in memory
Task2 is already in memory
VM2 is already in memory
-> VM2->Status has not been updated so
VM2->Status is still idle -> start Task2
-> Bug!!!
At this point we have two tasks trying to run on a single VM. When the
first one completes the VM gets powered off, leaving the second one
hanging.
With this patch VM1 and VM2 are the same object, and thus we
always have VM1->Status == VM2->Status which fixes this issue.
---
testbot/lib/WineTestBot/Jobs.pm | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/testbot/lib/WineTestBot/Jobs.pm b/testbot/lib/WineTestBot/Jobs.pm
index 1bf9de6..8e36a32 100644
--- a/testbot/lib/WineTestBot/Jobs.pm
+++ b/testbot/lib/WineTestBot/Jobs.pm
@@ -429,11 +429,12 @@ $MaxVMsWhenIdle VMs (or $MaxActiveVMs if not set) for future jobs.
=back
=cut
-sub ScheduleOnHost($$)
+sub ScheduleOnHost($$$)
{
- my ($SortedJobs, $Hypervisors) = @_;
+ my ($ScopeObject, $SortedJobs, $Hypervisors) = @_;
- my $HostVMs = CreateVMs();
+
+ my $HostVMs = CreateVMs($ScopeObject);
$HostVMs->FilterEnabledRole();
$HostVMs->FilterHypervisors($Hypervisors);
@@ -674,7 +675,7 @@ sub ScheduleJobs()
# we should check if there are VMs to revert
my %Hosts;
- my $VMs = CreateVMs();
+ my $VMs = CreateVMs($Jobs);
$VMs->FilterEnabledRole();
foreach my $VM (@{$VMs->GetItems()})
{
@@ -686,7 +687,7 @@ sub ScheduleJobs()
foreach my $Host (keys %Hosts)
{
my @HostHypervisors = keys %{$Hosts{$Host}};
- my $HostErrMessage = ScheduleOnHost(\@SortedJobs, \@HostHypervisors);
+ my $HostErrMessage = ScheduleOnHost($Jobs, \@SortedJobs, \@HostHypervisors);
push @ErrMessages, $HostErrMessage if (defined $HostErrMessage);
}
return @ErrMessages ? join("\n", @ErrMessages) : undef;
More information about the wine-cvs
mailing list