427919 - Create one win32 ref image for both build and unittest

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

For historical reasons, we have two different sets of ref images and ref platform definitions. One set for Build, the other set for Unittests. 

We want to have only one ref image & ref platform definition, in order to use a shared pool of identical slaves that can be allocated to do *either* Build or Unittest work.

Some differences that will need to be resolved are:
- we *believe* that these have the same toolchain installed on these, but in slightly different locations, with slightly different env.variables.
- different internal networks are used.
- different accounts are used. 

This bug is to track working through all this, and obsoleting the old ref images. 

(A separate bug should track whether we migrate all our existing VMs or just leave existing VMs as is.)

Comment 1

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Note: from discussion in meeting today, seem that win32 unittest machines are actual physical machines, not VMs. This was done as some tests were time dependent, and failed intermittently if running a (time variable) VM.

Questions:
Should unittests be reworked, and run on VMs, while builds remain on VMs?
Should unittests be run on dedicated hardware, while builds remain on VMs?
Should unittests remain on dedicated hardware, while builds are moved to run on dedicated hardware also?

Comment 2

[[e-mail] (:bhearsum)]

I think moving builds to physical hardware is something we explicitly want to avoid doing. I think this would increase maintenance burden, and we'd lose the ability to add hard drives, reboot, start, stop, etc. Not to mention the setup cost of moving our VMs to hardware.

IMHO, we should be using VMs unless there's a reason not to (such as unittest failures on them).

Comment 3

[Rob Campbell [:rc] (:robcee)]

for some historical retrospective on this, I've dug up bug 371172 which shows we were trying to get some faster cycles than the VMs were giving us.

Comment 4

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

We can now close this bug, as the remaining work was just completed in bug#460535.