Closed Bug 577154 Opened 14 years ago Closed 14 years ago

Add 15 linux64 build slaves to production pool

Categories

(Release Engineering :: General, defect, P5)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: joduinn, Unassigned)

References

Details

(Whiteboard: [buildslaves])

After the VMs are created in bug#577152, this bug is to track any manual setup we need to do in the slaves, and the matching buildbot masters setup.
Whiteboard: [hardware]
Priority: -- → P2
Blocks: 578749
No longer blocks: 571331
Whiteboard: [hardware] → [hardware][buildduty]
Dependent bug as been WONTFIXED due to lack of ESX space.

Let's think of repurposing VMs from production.
Priority: P2 → --
Assigning to you John, to figure out where these machines should come from.
Assignee: nobody → joduinn
Whiteboard: [hardware][buildduty] → [buildslaves]
(In reply to comment #2)
> Assigning to you John, to figure out where these machines should come from.

We've got 42 ix machines now powered and racked in internap. Once we get the refimage setup (in bug#588957), and these machines imaged, then we can use this bug to track putting these ix slaves into production.

Nothing more for me to do here, so putting back in the pool.
Assignee: joduinn → nobody
Depends on: 588957
OS: Mac OS X → Linux
Summary: Add 11 linux64 build slaves to production pool → Add 42 linux64 build slaves to production pool
Priority: -- → P5
We have 39 linux64 slaves.  How many should be in production, staging and try?
My 2 cents: 3-5 for staging, split the rest evenly between prod and try. 

We could push more to try given they're always clobber builds, and try is about 50% of the pushes. The number of prod pushes will probably go up as more project branches get going though, and no way of knowing how much. 50/50 isn't a bad guess.
I was going to say the following but I guess we can shuffle later if needed.

> How does 3 on staging, 65% on try and 35% on mozilla-central sound like?
> 
> I say 65% instead of 50% (~% of monthly load) because try builds are clobber type.
> You could use the reports that anamarias wrote but the last 2-3 months do not
> have a normal/standard development load as we devs were blocked by FF4 and were
> using try much more.
summary of discussion with jhford. We're reduced from 42 ix machines because of "borrowed" machines for extra masters, and hardware failures, so only have 39 available to use:

To start with, lets allocate these as follows:
01 - refimage
02 - staging
18 - production builders
18 - tryserver builders


After these are deployed and we monitor load/wait times, we can rebalance pools as needed.
> 01 - refimage
linux64-ix-ref
> 02 - staging
linux64-ix-slave01, 02
> 18 - production builders
linux64-ix-slave03-21
> 18 - tryserver builders
linux64-ix-slave22-40
Summary: Add 42 linux64 build slaves to production pool → Add 39 linux64 build slaves to production pool
probably should have uploaded https://bugzilla.mozilla.org/attachment.cgi?id=522767&action=diff to this bug, but this is the patch to add these slaves to the buildbot configs
Status update:

bm1,bm2 correspond to buildbot-master%i.build.scl1.mozilla.com

linux64-ix-slave03.build.mozilla.org    bm1:9010
linux64-ix-slave05.build.mozilla.org    bm1:9010
linux64-ix-slave06.build.mozilla.org    bm1:9010
linux64-ix-slave07.build.mozilla.org    bm1:9010
linux64-ix-slave08.build.mozilla.org    bm1:9010
linux64-ix-slave09.build.mozilla.org    bm1:9010
linux64-ix-slave15.build.mozilla.org    bm2:9010
linux64-ix-slave17.build.mozilla.org    bm2:9010
linux64-ix-slave18.build.mozilla.org    bm2:9010
linux64-ix-slave19.build.mozilla.org    bm2:9010
linux64-ix-slave20.build.mozilla.org    bm2:9010
linux64-ix-slave21.build.mozilla.org    bm2:9010

Are all in production.
The remaining try machines are being tracked in bug 647049
Status: NEW → RESOLVED
Closed: 14 years ago
No longer depends on: 647043
Resolution: --- → FIXED
Summary: Add 39 linux64 build slaves to production pool → Add 15 linux64 build slaves to production pool
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.