New issue
Advanced search Search tips

Issue 669944 link

Starred by 1 user

Issue metadata

Status: Archived
Owner: ----
Closed: Dec 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

assign_stable_images fails with current omaha_status.json

Reported by jrbarnette@chromium.org, Nov 30 2016

Issue description

The most recent weekly run of assign_stable_images failed
with this exception traceback:

Traceback (most recent call last):
 File "site_utils/stable_images/assign_stable_images.py", line 407, in <module>
   main(sys.argv)
 File "site_utils/stable_images/assign_stable_images.py", line 399, in main
   _read_gs_json_data(_OMAHA_STATUS))
 File "site_utils/stable_images/assign_stable_images.py", line 265,
in _make_omaha_versions
   if e['channel'] == 'beta'])
 File "site_utils/stable_images/assign_stable_images.py", line 259,
in _get_omaha_data
   milestone = json_entry['chrome_version'].split('.')[0]
KeyError: 'chrome_version'

From the python CLI, you can see the following:
   >>> import json
   >>> fp = open('omaha_status.json')
   >>> d = json.load(fp)
   >>> [e['board']['public_codename'] for e in d['omaha_data'] if 'chrome_version' not in e]
   [u'arkham', u'arkham', u'gale', u'gale', u'gale', u'lakitu', u'whirlwind']

'gale', 'arkham', and 'lakitu' aren't in the lab, and so are
excluded from automated stable version assignment, but 'whirlwind'
_is_ on the list, and that would seem to be the source of the
failure.

As an OnHub device, 'whirlwind' doesn't actually have Chrome,
so it's reasonable that 'omaha_status.json' not report a
'chrome_version' field.  However, we need to know the Chrome
milestone to find the image file in gs://chromeos-image-archive.

There's no easy, standardized way to get a Chrome milestone
number from a version number like 8839.0.0, so I don't know how
to solve this right away.  But solve it we must, and ideally
before the next run on Tuesday, 12/6.
 
I've requested changes in the content in omaha_status.json;
see https://b2.corp.google.com/issues/33250855.

Meanwhile, I've done a slightly more detailed check to identify
the problem:
    >>> [e['board']['public_codename'] for e in d['omaha_data']
    ...   if 'chrome_version' not in e and e['channel'] == 'beta']
    [u'gale']

IOW, 'whirlwind' isn't the source of our current problems; it's gale.
And, there are no 'gale' DUTs in the lab, so we can punt by changing
assign_stable_images to exclude boards that don't have 'chromeos_version'
set.  That will tide us over until (roughly) when R57 hits beta for
whirlwind.

Project Member

Comment 2 by bugdroid1@chromium.org, Dec 2 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/a139497c980593b1c1cd036cd68a8dcfb20cfee2

commit a139497c980593b1c1cd036cd68a8dcfb20cfee2
Author: Richard Barnette <jrbarnette@chromium.org>
Date: Thu Dec 01 00:24:33 2016

[autotest] Ignore missing "chrome_version" in stable version assignment

In the Omaha JSON file, some entries (notably, the 'storm' product
family) don't have a "chrome_version" setting.  Beta channel entries
like this were causing the assign_stable_images script to fail.

The only board that currently causes failure is 'gale', which isn't
in the lab.  So, as a stopgap, we're changing to just ignore these
entries.

Eventually, this problem will show up in 'whirlwind', at which point
we'll lose the ability to assign a stable version for that board,
until there's some better fix.  That's expected to happen when R57
hits Beta.

BUG= chromium:669944 
TEST=unit tests, run with --dry-run

Change-Id: If56ffccc2f6e4a66fbdfacb110431301d5a6736f
Reviewed-on: https://chromium-review.googlesource.com/415566
Commit-Ready: Richard Barnette <jrbarnette@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Shuqian Zhao <shuqianz@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>

[modify] https://crrev.com/a139497c980593b1c1cd036cd68a8dcfb20cfee2/site_utils/stable_images/assign_stable_images.py
[modify] https://crrev.com/a139497c980593b1c1cd036cd68a8dcfb20cfee2/site_utils/stable_images/test_omaha_status.json
[modify] https://crrev.com/a139497c980593b1c1cd036cd68a8dcfb20cfee2/site_utils/stable_images/assign_stable_images_unittest.py

Project Member

Comment 3 by bugdroid1@chromium.org, Dec 3 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/09b9f6c3be230c44d40f563a23f2948573a4b67f

commit 09b9f6c3be230c44d40f563a23f2948573a4b67f
Author: Richard Barnette <jrbarnette@chromium.org>
Date: Thu Dec 01 00:24:33 2016

[autotest] Use "milestone" from omaha_status.json

The omaha_status.json file from GoldenEye now includes a 'milestone'
setting that can be used to directly calculate a milestone value
regardless of whether a board has a 'chrome_version' setting.  This
changes assign_stable_image to rely on 'milestone', rather than on
the old (not quite reliable) 'chrome_version'.

BUG= chromium:669944 
TEST=unit tests, run with --dry-run

Change-Id: I4825a445e7834cbe9c21cba4a6d9f3c40eb83b35
Reviewed-on: https://chromium-review.googlesource.com/416369
Commit-Ready: Richard Barnette <jrbarnette@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Shuqian Zhao <shuqianz@chromium.org>

[modify] https://crrev.com/09b9f6c3be230c44d40f563a23f2948573a4b67f/site_utils/stable_images/assign_stable_images.py
[modify] https://crrev.com/09b9f6c3be230c44d40f563a23f2948573a4b67f/site_utils/stable_images/test_omaha_status.json
[modify] https://crrev.com/09b9f6c3be230c44d40f563a23f2948573a4b67f/site_utils/stable_images/assign_stable_images_unittest.py

Status: Fixed (was: Available)

Comment 5 by dchan@google.com, Mar 4 2017

Labels: VerifyIn-58

Comment 6 by dchan@google.com, Apr 17 2017

Labels: VerifyIn-59

Comment 7 by dchan@google.com, May 30 2017

Labels: VerifyIn-60

Comment 8 by dchan@chromium.org, Aug 1 2017

Labels: VerifyIn-61

Comment 9 by dchan@chromium.org, Oct 14 2017

Status: Archived (was: Fixed)

Sign in to add a comment