Bug 98957 - Need a cr-linux debug EWS bot
: Need a cr-linux debug EWS bot
Status: RESOLVED FIXED
: WebKit
Tools / Tests
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2012-10-10 14:33 PST by
Modified: 2013-01-29 22:04 PST (History)


Attachments
Patch (8.60 KB, patch)
2013-01-29 19:05 PST, Alan Cutter
no flags Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-10-10 14:33:17 PST
We don't want the bots to be debug because then they'd be too slow. But running with just asserts enabled would probably be the sweet spot of catching debug-only test failures and still being fast to run.
------- Comment #1 From 2012-10-10 15:30:12 PST -------
Eric convinced me that all I really want it a debug EWS bot.
------- Comment #2 From 2012-10-10 15:39:31 PST -------
This is easy to set up.  We just need server resources.
------- Comment #3 From 2013-01-29 14:41:08 PST -------
This keeps coming up.  Folks break the debug build (compile) by accident.  It's very easy to do.
------- Comment #4 From 2013-01-29 15:18:46 PST -------
The main blocker here is server resources. I'm still waiting for a response from GCE on a request for more instance & CPU quota. I assume we would need at least as many bots as are on the chromium-ews queue (8 bots). We are currently using 13/16 bots in GCE.
------- Comment #5 From 2013-01-29 15:39:27 PST -------
I don't think we actually will need that many.  Build-only doesn't take very long.  If we fixed the existing EWS to not spin so much I suspect we'd have more than enough machines already. :)
------- Comment #6 From 2013-01-29 15:50:37 PST -------
There are some build stats on the chromium waterfall:
http://build.chromium.org/p/chromium.webkit/stats/WebKit%20Linux
http://build.chromium.org/p/chromium.webkit/stats/WebKit%20Linux%20%28dbg%29

It looks like compile times are comparable.  The big difference is the time it takes to run webkit_tests.  On the release bot, it's around 420sec and on the debug bot it's 935sec.  Since we skip flaky tests, it's not going to be exactly the same.  Also, it looks like the release bot has 8 cores and the debug bot has 24 cores.

Hmm, I guess it's not clear to me how much slower the debug bot is going to be, but it looks like at least 2x.
------- Comment #7 From 2013-01-29 15:51:47 PST -------
Oh, you just want compile only.  Yeah, looks like that should be pretty fast.  Maybe 3x slower considering that the debug build.chromium.org has 3x the number of cores, but I doubt it will be that much in practice.
------- Comment #8 From 2013-01-29 15:57:13 PST -------
Ah, I didn't know this was just for building, in that case 2 bots should probably be enough.
------- Comment #9 From 2013-01-29 19:05:09 PST -------
Created an attachment (id=185379) [details]
Patch
------- Comment #10 From 2013-01-29 19:11:14 PST -------
(From update of attachment 185379 [details])
OK.  LGTM.  We really should store the list of queues in the data store one of these days. :)
------- Comment #11 From 2013-01-29 19:11:45 PST -------
bubbles are hitting an exception:
Traceback (most recent call last):
  File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/_webapp25.py", line 714, in __call__
    handler.get(*groups)
  File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/handlers/statusbubble.py", line 78, in get
    bubbles, show_submit_to_ews = self._build_bubbles_for_attachment(attachment)
  File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/handlers/statusbubble.py", line 62, in _build_bubbles_for_attachment
    if not self._have_status_for(attachment, queue):
  File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/handlers/statusbubble.py", line 53, in _have_status_for
    if attachment.position_in_queue(queue):
  File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/model/attachment.py", line 81, in position_in_queue
    return self._queue_positions().get(queue.name())
  File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/model/attachment.py", line 97, in _queue_positions
    self._cached_queue_positions = self._calculate_queue_positions()
  File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/model/attachment.py", line 102, in _calculate_queue_positions
    return dict([(items.queue.name(), items.display_position_for_attachment(self.id)) for items in all_work_items])
AttributeError: 'NoneType' object has no attribute 'name'

Is that from this push?
------- Comment #12 From 2013-01-29 20:59:56 PST -------
(In reply to comment #11)
> bubbles are hitting an exception:
> Traceback (most recent call last):
>   File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/_webapp25.py", line 714, in __call__
>     handler.get(*groups)
>   File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/handlers/statusbubble.py", line 78, in get
>     bubbles, show_submit_to_ews = self._build_bubbles_for_attachment(attachment)
>   File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/handlers/statusbubble.py", line 62, in _build_bubbles_for_attachment
>     if not self._have_status_for(attachment, queue):
>   File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/handlers/statusbubble.py", line 53, in _have_status_for
>     if attachment.position_in_queue(queue):
>   File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/model/attachment.py", line 81, in position_in_queue
>     return self._queue_positions().get(queue.name())
>   File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/model/attachment.py", line 97, in _queue_positions
>     self._cached_queue_positions = self._calculate_queue_positions()
>   File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/model/attachment.py", line 102, in _calculate_queue_positions
>     return dict([(items.queue.name(), items.display_position_for_attachment(self.id)) for items in all_work_items])
> AttributeError: 'NoneType' object has no attribute 'name'
> 
> Is that from this push?

That was from me viewing the "pre-release" version causing a WorkItem to be created for the cr-linux-debug-ews queue which still doesn't exist in production causing a None to be let loose in the system. My mistake!

(In reply to comment #10)
> (From update of attachment 185379 [details] [details])
> OK.  LGTM.  We really should store the list of queues in the data store one of these days. :)

This sounds like a good idea and should avoid the aforementioned scenario!
------- Comment #13 From 2013-01-29 22:04:43 PST -------
(From update of attachment 185379 [details])
Clearing flags on attachment: 185379

Committed r141223: <http://trac.webkit.org/changeset/141223>
------- Comment #14 From 2013-01-29 22:04:48 PST -------
All reviewed patches have been landed.  Closing bug.