Swarm release 10.6 main waterfall bot.

Swarm release 10.6 main waterfall bot.

BUG=414808
TBR=maruel@chromium.org

Committed: https://chromium.googlesource.com/chromium/src/+/df970d9aa2bde09f93a09b91664a1582c037d10b

[M-A Ruel, 2014-10-07 14:50:43]

But there's no 10.6 bots on Swarming?

[commit-bot: I haz the power, 2014-10-07 14:54:30]

Patchset 1 (id:??) landed as
https://crrev.com/df970d9aa2bde09f93a09b91664a1582c037d10b
Cr-Commit-Position: refs/heads/master@{#298477}

[jam, 2014-10-07 14:54:59]

Committed patchset #1 (id:1) manually as
df970d9aa2bde09f93a09b91664a1582c037d10b (presubmit successful).

[M-A Ruel, 2014-10-07 14:55:16]

On 2014/10/07 14:50:43, M-A Ruel wrote:
> But there's no 10.6 bots on Swarming?

Oh we do! lgtm

[M-A Ruel, 2014-10-07 14:56:00]

On 2014/10/07 14:55:16, M-A Ruel wrote:
> On 2014/10/07 14:50:43, M-A Ruel wrote:
> > But there's no 10.6 bots on Swarming?
> 
> Oh we do! lgtm

That said, I'm not sure 4 is enough to sustain the load. We'll see.

[jam, 2014-10-07 15:14:21]

On 2014/10/07 14:56:00, M-A Ruel wrote:
> On 2014/10/07 14:55:16, M-A Ruel wrote:
> > On 2014/10/07 14:50:43, M-A Ruel wrote:
> > > But there's no 10.6 bots on Swarming?
> > 
> > Oh we do! lgtm
> 
> That said, I'm not sure 4 is enough to sustain the load. We'll see.

Yeah, they are also 4-core machines. The testers on the main waterfall are 8
core.

My plan was (I should have probably wrote this out explicitly earlier):
1) make 10.6 rel use swarming. it has 4 VMs to itself so it shouldn't be slower
than what it is now*
2) once I verify above works, move over 10.6 tests (2) to the swarming pool
3) stop 10.6 dbg tests (2) (which runs browser_tests). it's ok if we lose a few
iterations on it. move it to swarming pool
4) swarm 10.6 dbg
5) if bot cycle time > 30 minutes, ask for a few more VMs.

*The calculation I came up with was: right now the swarmed release tests take 44
minutes in total. That's on an 8 core machine. So say that takes 88 minutes on
4-core, it will still cycle in 22 minutes on the 4-core VMs. Once we have 2
4-core VMs and 1 8-core VM per debug/release, it will still be equivalent to 4
4-core VMs per debug/release. The debug swarmed tests would take about 120
minutes on a 4-core machine, so still only about 30 minutes using 4 of them.

[M-A Ruel, 2014-10-07 15:53:35]

On 2014/10/07 15:14:21, jam wrote:
> On 2014/10/07 14:56:00, M-A Ruel wrote:
> > On 2014/10/07 14:55:16, M-A Ruel wrote:
> > > On 2014/10/07 14:50:43, M-A Ruel wrote:
> > > > But there's no 10.6 bots on Swarming?
> > > 
> > > Oh we do! lgtm
> > 
> > That said, I'm not sure 4 is enough to sustain the load. We'll see.
> 
> Yeah, they are also 4-core machines. The testers on the main waterfall are 8
> core.
> 
> My plan was (I should have probably wrote this out explicitly earlier):
> 1) make 10.6 rel use swarming. it has 4 VMs to itself so it shouldn't be
slower
> than what it is now*
> 2) once I verify above works, move over 10.6 tests (2) to the swarming pool
> 3) stop 10.6 dbg tests (2) (which runs browser_tests). it's ok if we lose a
few
> iterations on it. move it to swarming pool
> 4) swarm 10.6 dbg
> 5) if bot cycle time > 30 minutes, ask for a few more VMs.
> 
> *The calculation I came up with was: right now the swarmed release tests take
44
> minutes in total. That's on an 8 core machine. So say that takes 88 minutes on
> 4-core, it will still cycle in 22 minutes on the 4-core VMs. Once we have 2
> 4-core VMs and 1 8-core VM per debug/release, it will still be equivalent to 4
> 4-core VMs per debug/release. The debug swarmed tests would take about 120
> minutes on a 4-core machine, so still only about 30 minutes using 4 of them.

Sounds good. Thanks for the explanation.