460535 - update win32 ref platform so build/unittest VMs can use this out-of-the-box

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P1)

Description

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

There are two differences between the win32 build VMs and the win32 unittest VMs. 

1) Adding missing setting for MOZ_NO_RESET_PATH=1 as system-wide environment variable

2) Changing display/monitor settings so that build machines use the same resolution and color depth as the unittest machines (1280 x 1024, with 24bit color depth).

mrz has brought up the template VMs, so I can make these changes.

Comment 1

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

(In reply to comment #1)
> There are two differences between the win32 build VMs and the win32 unittest
> VMs. 
> 
> 1) Adding missing setting for MOZ_NO_RESET_PATH=1 as system-wide environment
> variable
Done.


> 2) Changing display/monitor settings so that build machines use the same
> resolution and color depth as the unittest machines (1280 x 1024, with 24bit
> color depth).
Interesting. I cant get the required resolution/colordepth, even after installing VMware tools. Compared both build and unittest VMs to verify they have the same "Display adapter of VMare SVGA II". However, the ref image only shows choices of 16bit/32bit color depth, not the desired 24bit color depth. 

robc: can you give any background on how you set this for unittest VMs originally?

Comment 2

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

see bug 414720 for history.

Comment 3

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

Cool, thanks Robcee, that did the trick nicely. The color depth and screen resolution are now correctly set to 1280 x 1024, 24bit color. (heh, and now, looking for "gpedit.msc" I find it on wiki also.)

win32 ref image VM "win2k3sp2-vc8tools-ref-vm" should now be able to create clones which can work for either builds and/or unittests.

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

We also need to install pskill so that unit test can kill stuff off at the start of the run. We'll need to check how it's installed and included on the path on existing machines.

We should also consider taking the twisted downgrade and patch to kill process groups (bug 420216), and figure out how to fix the prompts to debug (bug 453260).

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

The win32 refplatform doc
  https://wiki.mozilla.org/ReferencePlatforms/Win32#Disable_JIT_Debugger
calls for 
  HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\DbgJITDebugLaunchSetting
to be set to 1, but it's set to octal 10 on moz2-win32-slave05, 06, 12, 13 - probably anything from 5 onwards. I bet this causes bug 453260.

The two keys under
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\AeDebug
are set correctly.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #1)
> (In reply to comment #1)
> > 1) Adding missing setting for MOZ_NO_RESET_PATH=1 as system-wide environment
> > variable
> Done.

Do we understand why this is necessary ? ie why should we not reset the path when starting msys for unittest ? Seems strange since we start buildbot from a cmd prompt there.

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #5)
> The win32 refplatform doc
>   https://wiki.mozilla.org/ReferencePlatforms/Win32#Disable_JIT_Debugger
> calls for 
>   HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\DbgJITDebugLaunchSetting
> to be set to 1

I have updated the reference platform, and will check all the windows machines in bug 453260.

Comment 8

[[e-mail] (:bhearsum)]

(In reply to comment #6)
> (In reply to comment #1)
> > (In reply to comment #1)
> > > 1) Adding missing setting for MOZ_NO_RESET_PATH=1 as system-wide environment
> > > variable
> > Done.
> 
> Do we understand why this is necessary ? ie why should we not reset the path
> when starting msys for unittest ? Seems strange since we start buildbot from a
> cmd prompt there.

Honestly, I don't remember why I found it necessary when I originally setup the mozilla-central Buildbot. I think if we defined PATH in config.py we could get along without it - I'm not entirely sure though.

Comment 9

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

From irc discussion, we should also tweak VM template: 
- from 1gb RAM to 2gb RAM
- add drive e with 30gb 

(currently, both of these need manual changes during cloning, which have caused problems with recent VM clone requests).

Comment 10

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

how about also:
- pre-formatting the new e: drive as FAT32, with volume name "build"
- putting the staging ssh keys on the ref image. We should still make explicit manual step to put on production ssh keys, but the staging keys we use right away, afaict.

...as they seemed the big ones items on https://wiki.mozilla.org/ReferencePlatforms/Win32#Manual_Setup_Steps_after_VMImage and https://wiki.mozilla.org/Buildbot/Unittest/SlaveSetup: 


Is there anything else? Could we consolidate these two wiki pages now?

Comment 11

[Chris AtLee [:catlee]]

The reference image has been updated to have more RAM and a 30GB drive E:.  I also copied over the staging ssh keys and the D:\Utilities directory (which includes pskill).

I think the Unittest/SlaveSetup page could be removed, but maybe Lukas wants to double check.