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]

Module: tools
Branch: master
Commit: ad5dc5add5223edefd45ab693d238be5208b1c74
URL:    http://source.winehq.org/git/tools.git/?a=commit;h=ad5dc5add5223edefd45ab693...

Author: Francois Gouget 
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;