Closed Bug 780022 Opened 12 years ago Closed 11 years ago

[tracker] reimage 73 linux32, linux64 ix builders as win64 builders


(Infrastructure & Operations Graveyard :: CIDuty, task)

Not set


(Not tracked)



(Reporter: joduinn, Assigned: hwine)



(Whiteboard: [tracker] [reit])

(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.
Whiteboard: [tracker]
Depends on: 774829
No longer depends on: 712456
Depends on: 712456
No longer depends on: 774829
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.
Whiteboard: [tracker] → [tracker] [reit]
Moved the mv-moz2-linux machines to bug 784721, and the upgrade dependency with them.
No longer depends on: 712456
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)
Assignee: hwine → dustin
VLANs are changed to vlan40.
Assignee: dustin → mlarrain
Depends on: 784850
Added these to DHCP in Windows will started the reimaging process shortly
Blocks: 758275
Blocks: 784891
No longer blocks: 758275
(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.
QA Contact: armenzg → arich
Assignee: mlarrain → arich
QA Contact: arich → armenzg
: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.
Summary: reimage linux32, linux64 ix builders as win64 builders → [tracker] reimage linux32, linux64 ix builders as win64 builders
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.
Assignee: arich → hwine
Depends on: 786035
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
Summary: [tracker] reimage linux32, linux64 ix builders as win64 builders → [tracker] reimage 73 linux32, linux64 ix builders as win64 builders
Depends on: 795496
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) has address has address has address has address has address has address has address has address has address has address has address has address

It seems that these have been decommissioned:

According to the esr cycle [1] we would need to keep those machines around until Firefox 25 ships which is in 2013-10-29 [1][2]

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?

Blocks: 863236
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
Closed: 11 years ago
Resolution: --- → FIXED
Product: → Release Engineering
Product: Release Engineering → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.