Closed
Bug 616351
Opened 14 years ago
Closed 13 years ago
slave-side slave-alloc support for win32
Categories
(Release Engineering :: General, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: dustin, Assigned: dustin)
References
Details
(Whiteboard: [slavealloc])
Attachments
(4 files)
3.95 KB,
patch
|
bhearsum
:
review+
dustin
:
checked-in+
|
Details | Diff | Splinter Review |
572 bytes,
patch
|
bear
:
review+
dustin
:
checked-in+
|
Details | Diff | Splinter Review |
437 bytes,
patch
|
bhearsum
:
review+
dustin
:
checked-in+
|
Details | Diff | Splinter Review |
1.49 KB,
patch
|
bhearsum
:
review+
dustin
:
checked-in+
|
Details | Diff | Splinter Review |
Similar to bug 616003, but for win32 systems. As I understand it, these are build slaves only, and are controlled by OPSI, so this means deploying runslave.py with OPSI and adjusting the other equipment to run it.
Assignee | ||
Comment 1•13 years ago
|
||
I can do this, but this would be a great place to get some help on this project (along with bug 629690 and bug 629692)
Assignee: dustin → nobody
Updated•13 years ago
|
OS: All → Windows XP
Priority: -- → P3
Hardware: All → x86
Whiteboard: [slavealloc]
Assignee | ||
Comment 2•13 years ago
|
||
This is the OPSI config to install runslave.py. This drops both of the start-buildbot-repeatedly loops. I'll run this in staging for a while, and re-add that (well, one loop anyway) if it turns out to be necessary. I had trouble with bash crashing while running the shell script (yes, really), so I took that out. This works and runs runslave.py, but the currrent 'tip' version of runslave has a typo that prevents it from starting things up.
Assignee: nobody → dustin
Attachment #533168 -
Flags: review?(bhearsum)
Assignee | ||
Comment 3•13 years ago
|
||
This fixes the typo in runslave.py (indentation error that caused it not to find python.exe under D:).
Attachment #533169 -
Flags: review?(bear)
Comment 4•13 years ago
|
||
Comment on attachment 533168 [details] [diff] [review] m616351-opsi-package-sources-r1.patch Looks reasonable to me.
Attachment #533168 -
Flags: review?(bhearsum) → review+
Comment 5•13 years ago
|
||
Comment on attachment 533169 [details] [diff] [review] m616351-puppet-manifests-r1.patch *stamp*
Attachment #533169 -
Flags: review?(bear) → review+
Assignee | ||
Updated•13 years ago
|
Attachment #533169 -
Flags: checked-in+
Assignee | ||
Updated•13 years ago
|
Attachment #533168 -
Flags: checked-in+
Assignee | ||
Comment 6•13 years ago
|
||
Oops, I don't want the package to always install 'tip' - rather, it should specify a particular hg revision, and we'll bump the package revision when that changes.
Attachment #533370 -
Flags: review?(bhearsum)
Updated•13 years ago
|
Attachment #533370 -
Flags: review?(bhearsum) → review+
Assignee | ||
Comment 7•13 years ago
|
||
Comment on attachment 533370 [details] [diff] [review] m616351-opsi-package-sources-p2.patch I'm seeing problems with the startup failures - it looks like some percentage of the invocations of Python just fail immediately. This used to happen, so it's not horribly surprising that it's still going on. I'll try to write a loop that will restart runslave.py if it fails quickly, but will just die if it takes a while to exit (e.g., after a build). The staging slaves are also failing to build with an incorrect %PATH%. That will need to be fixed first.
Attachment #533370 -
Flags: checked-in+
Assignee | ||
Comment 8•13 years ago
|
||
This updates the revision to point to the new runslave.py from bug 658024, and fixes the %PATH% problem. It doesn't address the looping problem because I haven't been able to replicate it since the first time I ran runslave.py (and that may have been operator error).
Attachment #533469 -
Flags: review?(bhearsum)
Updated•13 years ago
|
Attachment #533469 -
Flags: review?(bhearsum) → review+
Assignee | ||
Comment 9•13 years ago
|
||
Comment on attachment 533469 [details] [diff] [review] m616351-opsi-package-sources-p3.patch Still working on this - bug 658263 - before pushing it into production.
Attachment #533469 -
Flags: checked-in+
Assignee | ||
Comment 10•13 years ago
|
||
OK, deployed to production.
Assignee | ||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•