New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 847540 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

Out of band ToT suites not getting scheduled to run on M69 since branch on Friday

Project Member Reported by harpreet@chromium.org, May 29 2018

Issue description

Branch was on Friday which means ToT is now M69. But looks like wifi tests are still running on M68 for all our wifi suites that are setup to run on ToT. 

You can see jobs that have been scheduled/run at the below links:

snappy: http://cautotest/afe/#tab_id=view_host&object_id=8453
chell: http://cautotest/afe/#tab_id=view_host&object_id=7977


Why is lab not scheduling test runs on M69 ToT yet?



FYI - Here are some of the wifi suites scheduled/setup in suite_scheduler:

[WiFi_MatFunc]
owner: chromeos-kernel-wifi@google.com
run_on: nightly
hour: 8
suite: wifi_matfunc
branch_specs: ==tot
pool: wificell
only_hwtest_sanity_required: True

[WiFi_Flaky]
owner: chromeos-kernel-wifi@google.com
run_on: nightly
hour: 1
suite: wifi_flaky
branch_specs: ==tot
pool: wificell
only_hwtest_sanity_required: True

[WiFi_EndtoEnd]
owner: chromeos-kernel-wifi@google.com
run_on: nightly
hour: 8
suite: wifi_endtoend
branch_specs: ==tot
pool: wificell
only_hwtest_sanity_required: True

[WiFi_Perf]
owner: chromeos-kernel-wifi@google.com
run_on: nightly
hour: 8
suite: wifi_perf
branch_specs: ==tot
pool: wificell
only_hwtest_sanity_required: True

 
Cc: dchan@chromium.org ka...@chromium.org

Comment 2 by ka...@chromium.org, May 29 2018

Same for chameleon_audio_nightly and chameleon_hdmi_nightly. They are set to run on tot-1, but executing M67 at this time.

Comment 3 by ka...@chromium.org, May 29 2018

Components: Test

Comment 4 by ka...@chromium.org, May 29 2018

It seems this scheduling issue affects only nightly suites, though I can find some(not many) nightly suites executed on ToT like security, power_daily, ent-nightly.
Cc: jrbarnette@chromium.org cros-fw-te@google.com xixuan@chromium.org mruthven@chromium.org
 Issue 847560  has been merged into this issue.

Comment 6 by xixuan@chromium.org, May 29 2018

suite-scheduler gets ToT from: gs://chromeos-image-archive/master-paladin/LATEST-master

xixuan@xixuan0:~/chromiumos/chromite$ gsutil cat gs://chromeos-image-archive/master-paladin/LATEST-master
R68-10718.0.0-rc2

which means currently the ToT is R68. 

Which resource is the right one for us to get correct ToT? I checked gs://chromeos-image-archive/master-release/LATEST-master, it's R69.
> suite-scheduler gets ToT from: gs://chromeos-image-archive/master-paladin/LATEST-master

That seems wrong.

I also think it would explain the failure; the CQ has been red enough
that it maybe hasn't had a clean build since the branch.


> Which resource is the right one for us to get correct ToT? I checked gs://chromeos-image-archive/master-release/LATEST-master, it's R69.

That sure looks like the right place to be looking, but I don't know
what considerations went into the choice.

Comment 8 by xixuan@chromium.org, May 29 2018

Cc: leecy@chromium.org
I feel the intention to use master-paladin/LATEST-master is paladin is usually better maintained, which should be newest, at least newer than master-release.

Anyone in this bug knows what's the right place to check ToT? 

Even if I change it to use master-release, if release is red enough ,the LATEST-master could be out-of-date?

> I feel the intention to use master-paladin/LATEST-master is paladin
> is usually better maintained, which should be newest, at least newer
> than master-release.

... But suite scheduler schedules against the release builds, not
the paladin builds.


> Even if I change it to use master-release, if release is red enough ,
> the LATEST-master could be out-of-date?

Since tests are scheduled against master-release builds, if the release
is red enough, we can't test anyway.

Right now, we failed to test because the CQ was continuously red after
the branch, even though the canary had produced green builds on the new
ToT.  If we were using master-release, that likely wouldn't have happened.

> Since tests are scheduled against master-release builds, if the release
> is red enough, we can't test anyway.

... I'm remembering something else...  The master release build is pretty
much _always_ green, because it won't turn red for individual slave builders.
I think that also still mostly means we should prefer to use the canary.

Cc: bhthompson@chromium.org
Owner: xixuan@chromium.org
Cc: -bhthompson@chromium.org bhthompson@google.com
Project Member

Comment 15 by bugdroid1@chromium.org, Jun 4 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/infra/suite_scheduler/+/7899db53b3b363818201c9a54a39df08d90e0de0

commit 7899db53b3b363818201c9a54a39df08d90e0de0
Author: Xixuan Wu <xixuan@chromium.org>
Date: Tue May 29 21:19:09 2018

suite-scheduler: Change to use master-release as ToT.

BUG= chromium:847540 
TEST=Ran unittest.

Change-Id: I0087c9571f5b67cdd781b7d7f191c53de637e896

[modify] https://crrev.com/7899db53b3b363818201c9a54a39df08d90e0de0/build_lib.py

Status: Fixed (was: Assigned)

Sign in to add a comment