Closed Bug 629690 Opened 15 years ago Closed 14 years ago

slave-side slave-alloc support for win64

Categories

(Release Engineering :: General, defect, P4)

x86_64
Windows Server 2008
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dustin, Assigned: armenzg)

References

Details

(Whiteboard: [slavealloc])

Attachments

(2 files, 2 obsolete files)

+++ This bug was initially created as a clone of Bug #616351 +++ Similar to bug 616003, but for win64 systems. These systems are as yet not in production, so doing the deployment now will be easier than doing it later!
Summary: slave-side slave-alloc support for win32 → slave-side slave-alloc support for win64
Depends on: 629694
OS: All → Windows 7
Priority: -- → P3
Hardware: All → x86_64
Whiteboard: [slavealloc]
Depends on: 632103
Depends on: 622980
Not blocking bug 605278 anymore, as these systems aren't in production.
Assignee: nobody → armenzg
No longer blocks: 605278
Priority: P3 → P5
Assignee: armenzg → nobody
Assignee: nobody → armenzg
OS: Windows 7 → Windows Server 2008
Priority: P5 → P2
Status: NEW → ASSIGNED
Check that runslave.py is really in C:\ - the VirtualVault stuff messed me up.
No longer blocks: 615301
This got added on https://wiki.mozilla.org/ReferencePlatforms/Win64#Startup_scripts_.26_slave-alloc Waiting on machines to be re-imaged so we can test it works for any other host besides the ref machine. We could try it on mw64-ix-slave01 but putting on the side for now.
Priority: P2 → P3
Assignee: armenzg → nobody
Priority: P3 → P4
In the interim, what other testing can we do on the new win64 image? Is it possible to get SSH installed, or tweak the VNC settings so they're better than the W764 talos machines were? Time sync? Cleanup tasks similar to those run on the w32 builders?
It is all installed. It even has the driver that makes VNC to work better. Please check the ref docs if you want to double check anything. The only part that is missing is to add entries to the actual slave alloc DB and verify that slaves connect to the specified masters.
Attached patch ensure that basedir exists (obsolete) — Splinter Review
Assignee: nobody → armenzg
Attachment #544794 - Flags: review?(dustin)
Comment on attachment 544794 [details] [diff] [review] ensure that basedir exists I'm not sure why the existing basedir-creation code doesn't work, but it would be much better to make this directory when writing the buildbot.tac (in the download method), rather than in a "get_" function (which should not have any side-effects).
Attachment #544794 - Flags: review?(dustin) → review-
Attached patch ensure that basedir exists v1 (obsolete) — Splinter Review
Attachment #544794 - Attachment is obsolete: true
Attachment #544831 - Flags: review?(dustin)
Comment on attachment 544831 [details] [diff] [review] ensure that basedir exists v1 Review of attachment 544831 [details] [diff] [review]: ----------------------------------------------------------------- ::: modules/buildslave/files/runslave.py @@ +118,5 @@ > elif slave_matches('xp', 'w7', 'w764'): > basedir = dirs['win_test'] > > + # ensure the basedir exists so we can write the buildbot.tac file > + self.ensure_basedir_exists() This call should go away - this method should only be called just before creating the tac file
Attachment #544831 - Flags: review?(dustin) → review-
Addressed the comment. r+ through IRC.
Attachment #544831 - Attachment is obsolete: true
Attachment #544834 - Flags: review+
Comment on attachment 544834 [details] [diff] [review] ensure that basedir exists v1 This got landed and deployed: http://hg.mozilla.org/build/puppet-manifests/rev/1bbb72f7dcea
Attachment #544834 - Flags: checked-in+
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: