Closed
Bug 682408
Opened 13 years ago
Closed 13 years ago
setup mw32-ix-slave02, mw32-ix-slave20, w32-ix-slave03, w32-ix-slave23, w32-ix-slave26, w32-ix-slave29, w32-ix-slave34 and w32-ix-slave41
Categories
(Release Engineering :: General, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: armenzg, Assigned: armenzg)
References
Details
Attachments
(1 file)
2.49 KB,
patch
|
armenzg
:
review+
armenzg
:
checked-in+
|
Details | Diff | Splinter Review |
These got reimaged: mw32-ix-slave02.build.mtv1 w32-ix-slave03.build.scl1 w32-ix-slave23.build.scl1 w32-ix-slave26.build.scl1 w32-ix-slave29.build.scl1 w32-ix-slave41.build.scl1
Assignee | ||
Updated•13 years ago
|
Summary: setup mw32-ix-slave02, w32-ix-slave03, w32-ix-slave23, w32-ix-slave26, w32-ix-slave29 and → setup mw32-ix-slave02, w32-ix-slave03, w32-ix-slave23, w32-ix-slave26, w32-ix-slave29 and w32-ix-slave41
Assignee | ||
Comment 1•13 years ago
|
||
production-opsi:~# opsi-admin -d method deleteClient mw32-ix-slave02.uib.local production-opsi:~# opsi-admin -d method deleteClient w32-ix-slave03.uib.local production-opsi:~# opsi-admin -d method deleteClient w32-ix-slave23.uib.local production-opsi:~# opsi-admin -d method deleteClient w32-ix-slave26.uib.local production-opsi:~# opsi-admin -d method deleteClient w32-ix-slave29.uib.local production-opsi:~# opsi-admin -d method deleteClient w32-ix-slave41.uib.local * fixed hostname and rebooted * I have marked the "nagios" package to be re-deployed (see bug 677888 for details) * I have marked them to get buildbot-production installed (ftr win32-ix-ref has it marked as installed) Could these slaves have been reimaged from win2k3-ref-img instead of win32-ix-ref? (I see the package buildbot-production not marked as "installed" in the former which matches the state of the slaves cloned). w32-ix-slave03 is down - see bug 682574.
Assignee: nobody → armenzg
Status: NEW → ASSIGNED
Assignee | ||
Comment 3•13 years ago
|
||
w32-ix-slave34 will be reimaged in bug 682931 from a new snapshot and hopefully the problems of the first batch won't happen to it. I will do the setup of this slave in this bug as well.
Assignee | ||
Updated•13 years ago
|
Assignee | ||
Updated•13 years ago
|
Summary: setup mw32-ix-slave02, w32-ix-slave03, w32-ix-slave23, w32-ix-slave26, w32-ix-slave29 and w32-ix-slave41 → setup mw32-ix-slave02, w32-ix-slave03, w32-ix-slave23, w32-ix-slave26, w32-ix-slave29, w32-ix-slave34 and w32-ix-slave41
Assignee | ||
Comment 6•13 years ago
|
||
w32-ix-slave34 has had disk errors. arr needed an mtv slave so I decided to give her mw32-ix-slave20. mw32-ix-slave20 was allocated to the buildbot-0.7 pool so it wasn't taking any jobs. production-opsi:~# opsi-admin -d method deleteClient w32-ix-slave34.uib.local production-opsi:~# opsi-admin -d method deleteClient mw32-ix-slave20.uib.local [3:58pm] arr: armenzg: hm, so when I boot the new snapshot, I get a message saying that c: needs to be checked [3:58pm] arr: and then it proceeds to spit out a LOT of errors [3:58pm] arr: is there a machine in mtv1 I could reimage?
Summary: setup mw32-ix-slave02, w32-ix-slave03, w32-ix-slave23, w32-ix-slave26, w32-ix-slave29, w32-ix-slave34 and w32-ix-slave41 → setup mw32-ix-slave02, mw32-ix-slave20, w32-ix-slave03, w32-ix-slave23, w32-ix-slave26, w32-ix-slave29, w32-ix-slave34 and w32-ix-slave41
Assignee | ||
Comment 7•13 years ago
|
||
I will be moving w32-ix-slave24 into the buildpool and w32-ix-slave23 into the try pool to make the configs less jumpy. bhearsum gave me r+ on IRC.
Attachment #557168 -
Flags: review+
Assignee | ||
Comment 8•13 years ago
|
||
Comment on attachment 557168 [details] [diff] [review] allow mw32-ix-slave20 and w32-ix-slave24 to be part of the production pool I will have to wait until the releases go through so I can add the win32 slaves to the buildpool. I would not like to take a chance to affect any release build because I missed something on my testing.
Attachment #557168 -
Flags: checked-in+
Comment 9•13 years ago
|
||
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #7) > I will be moving w32-ix-slave24 into the buildpool and w32-ix-slave23 into > the try pool to make the configs less jumpy. Has this happened yet? I ask because both slaves are currently spamming the twistd.log on bm14 with unauthorized login exceptions. On logging in, first thing I noticed was that the date was set to to Sept 5th on w32-ix-slave23. I fixed that, and have disabled the 2 slaves in slavealloc until you have a chance to look at this.
Assignee | ||
Comment 10•13 years ago
|
||
I have put the following slaves back into production: mw32-ix-slave02 - connected to build-sjc1 (it could give time out issues) mw32-ix-slave20 - connected to build-sjc1 (it could give time out issues) w32-ix-slave08 - as a try slave w32-ix-slave24 - as a build slave (swapped with slave23) w32-ix-slave26 w32-ix-slave29 w32-ix-slave34 w32-ix-slave41 I will watch over them. w32-ix-slave23 - as a try slave - waiting on reconfig
Comment 11•13 years ago
|
||
landed with 2011-09-06 reconfig
Assignee | ||
Comment 12•13 years ago
|
||
All of these slaves have been taking several jobs and have been successful.
Status: ASSIGNED → 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
•