New issue
Advanced search Search tips

Issue 812428 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression

Blocking:
issue 819719
issue 812028



Sign in to add a comment

Triggering swarming tasks locally on chromium-swarm broken

Project Member Reported by bsheedy@chromium.org, Feb 14 2018

Issue description

Triggering a swarming task from a workstation fails immediately due to what looks like an issue with vpython, but (what should be) the same task triggered from the bots works fine.

Example bot-triggered task: https://chromium-swarm.appspot.com/task?id=3baf6eac8026c010&refresh=10&show_raw=1

Example locally-triggered task: https://chromium-swarm.appspot.com/task?id=3baf7a20878c3a10&refresh=10&show_raw=1

This occurs both using "mb.py run --swarmed ..." and using separate isolate/archive/trigger steps.
 
Cc: dpranke@chromium.org vadimsh@chromium.org jbudorick@chromium.org iannucci@chromium.org bpastene@chromium.org
Components: Infra>Client>Chrome
Labels: -Type-Bug Type-Bug-Regression
Owner: ----
Status: Available (was: Assigned)
If I understand what's happening, this has been broken for a while now (at least for some subset of tests, now probably for all tests).

I had assumed that the correct place to inject 'vpython' into swarming tasks was inside the recipe (specifically the swarming recipe module: https://chromium.googlesource.com/chromium/tools/build/+/master/scripts/slave/recipe_modules/swarming/api.py#18, introduced a couple months ago here: https://chromium.googlesource.com/chromium/tools/build/+/7391efc442e81d108e78855f55589a7b90efb196).

I wasn't aware of this usage of mb to trigger swarming test tasks directly. The most direct approach would be to add (yet another) copy of these pins into mb... I would really like to avoid this, as I already dislike the extra set of pins in the swarming module.

Some alternative approaches:
  1. Move the pins from the swarming module to mb.py. I'm not sure if all the extra stuff is 'plumbed through' the recipes already so that mb can own these pins (including the environment variable prefix support). This is a bit unfortunate, but not completely awful. It doesn't eliminate this extra set of pins, and will increase the rollout latency for new versions.
  2. Have mb read the current pin information from https://chrome-internal.googlesource.com/infradata/config/+/master/configs/cr-buildbucket/swarming_task_template.json. This reflects the currently-in-production version of packages used for all LUCI builds. This, in combination with having mb generate this aspect of the swarming task, would mean that buildbot and LUCI builds would always agree on these versions (currently it's a separate roll).

If we go with approach 2 (which I think I'm liking the more I think about it), I'll probably also adjust buildbot to use the same set of pinned packages. This would mean that the task template there would be the single source-of-truth for "what is in prod".

There's a smaller-scoped change here which would be to have mb read this information only when triggering locally.
It seems like it'd be better for this to be configured src-side, and you shouldn't have the packages pinned build-side at all. 

This is one of the reasons I don't like the current way we rely on CIPD packages for swarming tasks, it's too easy for the task to become not hermetic. I.e., it shouldn't be in mb.py either, it should be expressed as data dependencies in the build or in the //testing/buildbot/*.json files, along with all the other things that describe how the task is run.

(2) is problematic for other reasons as well because I don't think we want mb.py to have to be able to talk to an internal repo. 
Is there a way to work around this in the meantime? There's at least one issue I'm currently investigating that I can't reproduce locally, so I need to run tests on swarming.
Blockedon: 812028
Blocking: 812028
Blockedon: -812028
Project Member

Comment 7 by bugdroid1@chromium.org, Mar 1 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/64d2f02cddda0801ee45731afb25abdff3e3440c

commit 64d2f02cddda0801ee45731afb25abdff3e3440c
Author: Robert Iannucci <iannucci@chromium.org>
Date: Thu Mar 01 22:34:38 2018

[mb.py] Workaround for mb.py to include "base" software

Bug: 812428
Change-Id: I8561fce9eb8a2da3cf45530ccf1494d6182f48d5
Reviewed-on: https://chromium-review.googlesource.com/942226
Commit-Queue: Robbie Iannucci <iannucci@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#540310}
[modify] https://crrev.com/64d2f02cddda0801ee45731afb25abdff3e3440c/tools/mb/mb.py

`mb.py -s` should work at least, now. The medium-term fix is go/swarming-pool-task-template
Project Member

Comment 9 by bugdroid1@chromium.org, Mar 2 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a8a446921e307fee4b737482b24559ba74de8055

commit a8a446921e307fee4b737482b24559ba74de8055
Author: bsheedy <bsheedy@chromium.org>
Date: Fri Mar 02 00:00:51 2018

Add pyserial to .vpython

Adds pyserial 3.4 to the .vpython file. This is currently only used
by the VR motion-to-photon latency test.

Bug: 812428
Change-Id: I56644689177394dfdba727be41bdf792386e0f2e
Reviewed-on: https://chromium-review.googlesource.com/943923
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#540354}
[modify] https://crrev.com/a8a446921e307fee4b737482b24559ba74de8055/.vpython

Project Member

Comment 10 by bugdroid1@chromium.org, Mar 2 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9f6cea1b567eac61e9dc3e7bd0b033bfa48e3625

commit 9f6cea1b567eac61e9dc3e7bd0b033bfa48e3625
Author: Xi Cheng <chengx@chromium.org>
Date: Fri Mar 02 03:21:10 2018

Revert "[mb.py] Workaround for mb.py to include "base" software"

This reverts commit 64d2f02cddda0801ee45731afb25abdff3e3440c.

Reason for revert: caused crbug/818054 with high confidence

Original change's description:
> [mb.py] Workaround for mb.py to include "base" software
> 
> Bug: 812428
> Change-Id: I8561fce9eb8a2da3cf45530ccf1494d6182f48d5
> Reviewed-on: https://chromium-review.googlesource.com/942226
> Commit-Queue: Robbie Iannucci <iannucci@chromium.org>
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#540310}

TBR=iannucci@chromium.org,dpranke@chromium.org

Change-Id: I45c320f611d0caa86f2d18ae31f4d3b015da2e62
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 812428
Reviewed-on: https://chromium-review.googlesource.com/945368
Reviewed-by: Xi Cheng <chengx@chromium.org>
Commit-Queue: Xi Cheng <chengx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#540434}
[modify] https://crrev.com/9f6cea1b567eac61e9dc3e7bd0b033bfa48e3625/tools/mb/mb.py

Project Member

Comment 11 by bugdroid1@chromium.org, Mar 2 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5a9d75f6abae6a2af0ff4976d00a6a4ae36475d5

commit 5a9d75f6abae6a2af0ff4976d00a6a4ae36475d5
Author: Robert Iannucci <iannucci@chromium.org>
Date: Fri Mar 02 05:28:20 2018

Reland "[mb.py] Workaround for mb.py to include "base" software"

This is a reland of 64d2f02cddda0801ee45731afb25abdff3e3440c

It wasn't related to  crbug.com/818054  at all :)

Original change's description:
> [mb.py] Workaround for mb.py to include "base" software
>
> Bug: 812428
> Change-Id: I8561fce9eb8a2da3cf45530ccf1494d6182f48d5
> Reviewed-on: https://chromium-review.googlesource.com/942226
> Commit-Queue: Robbie Iannucci <iannucci@chromium.org>
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#540310}

Tbr: chengx@chromium.org
Bug: 812428, 818054 
Change-Id: I32685152c837abfb904402a0625a5da1ffbf2a66
Reviewed-on: https://chromium-review.googlesource.com/945369
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
Commit-Queue: Robbie Iannucci <iannucci@chromium.org>
Cr-Commit-Position: refs/heads/master@{#540453}
[modify] https://crrev.com/5a9d75f6abae6a2af0ff4976d00a6a4ae36475d5/tools/mb/mb.py

Blocking: 819719
Is this fixed?
I don't believe so - the workarounds for this is are still in place and I haven't heard about anything for a while. Plus, Robbie has been OOO for a while, so I don't know if anyone is currently driving this.
Cc: -iannucci@chromium.org iannu...@google.com

Sign in to add a comment