(In meeting w/Melissa this morning, and now w/hwine, we couldnt find a bug for this despite prior discussions/meetings, so filing now for tracking.)
Once we offload production linux desktop builds to AWS, (bug#772446), please reimage the linux32, linux64 ix builders as win64 builders. Increasing our win64 pool like this should help improve wait times on our win32, win64 builds.
Filing in RelEng for now, while we figure out logistics of using new slaves on release trains, and how many physical linux32,64 builders can be spared for helping win64.
Note: For the ix machines in 650castro, bug#712456 tracks upgrading the physical hardware as part of moving these machines from 650castro to a "real" colo.
Converting the hardware that's already in scl1 is easier. Those machines include:
There are additional machines in mtv1 that need hardware upgrades to move to a datacenter, so that means additional time and effort, and we would need to find space for them in scl3 (how much space we have available in scl3 depends on how many w8 test boxes we purchase):
The remaining ix machines in mtv1 are mw32 machines and covered under a different bug.
Moved the mv-moz2-linux machines to bug 784721, and the upgrade dependency with them.
We will be moving all of the linux 32 & 64 bit boxes to windows 64 eventually. We will add batches that can be moved to this bug as they become available.
If there is any lead time needed before first move, please start that work if it's one shot (as done in bug 758275 comment #18)
Also, let us know a rough estimate of the turn around time on the reimaging and associated infrastructure changes per batch.
Based on current build/try waittimes, we can safely re-image the following machines to w64 now:
Linux (build slaves)
Linux64 (trybuild slaves)
VLANs are changed to vlan40.
Added these to DHCP in Windows will started the reimaging process shortly
(In reply to Chris Cooper [:coop] from comment #4)
These machines have been reimaged as w64.
hwine, coop, joduinn: are these all of the machines we'll be switching? If so, I'll close out this bug.
:arr - no, eventually all in comment #1 will be converted over time. Sounds like the first batch is done.
To avoid confusion, let do future batches in dependent bugs, and keep this one as the tracker for the full batch.
Sounds good, I'll reassign this one to you as a tracker and you can open up specific bugs in the relops queue for batches of machines for us to reimage.
updated summary - started with 83 in this bug (42 of lin32, 41 of lin64) from comment #1
10 in production with close of bug 786035
Next step: RelEng to identify next batch to reimage
Some of these machines could go ahead, the ones on try where we dropped non-mock builds already. See
for slaves with 'no builders' against them. Bug 804766 for *-vmw-*, I don't see a bug for the mac slaves.
What is the current status of this bug? Thanks!
The linux 32 and 64 machines were converted to foopies and mock builders. We have a handful (6 of each) left that will be decommissioned when they are no longer serving their current purpose. I don't think there's any further action left for this.
Are these the ones that are staying around a little longer? (I want to adjust slavealloc)
linux-ix-slave01.build.scl1.mozilla.com has address 10.12.48.195
linux-ix-slave02.build.scl1.mozilla.com has address 10.12.48.196
linux-ix-slave03.build.scl1.mozilla.com has address 10.12.48.197
linux-ix-slave04.build.scl1.mozilla.com has address 10.12.48.198
linux-ix-slave05.build.scl1.mozilla.com has address 10.12.48.199
linux-ix-slave06.build.scl1.mozilla.com has address 10.12.48.200
linux64-ix-slave01.build.scl1.mozilla.com has address 10.12.49.44
linux64-ix-slave02.build.scl1.mozilla.com has address 10.12.49.45
linux64-ix-slave03.build.scl1.mozilla.com has address 10.12.49.46
linux64-ix-slave04.build.scl1.mozilla.com has address 10.12.49.47
linux64-ix-slave05.build.scl1.mozilla.com has address 10.12.49.48
linux64-ix-slave06.build.scl1.mozilla.com has address 10.12.49.49
It seems that these have been decommissioned:
According to the esr cycle  we would need to keep those machines around until Firefox 25 ships which is in 2013-10-29 
Another alternative is if we had *vmw-* VMs (like we used to have) we could re-purpose those machines.
If we're fine to wait then we can wait.
On another, why do we have esr17 nightly builds?
Yes, we need to keep those machines for ESR17. We do nightlies on ESR so our partners can validate the builds before do the final release builds.
nothing more to do here