Remove the legacy `cros` verifier.
Reported by
jrbarnette@chromium.org,
Aug 1 2016
|
||||
Issue description
In the current CrosHost verification DAG, there's a
'cros' verifier that looks like this:
(repair.LegacyHostVerifier, 'cros', ['ssh']),
The LegacyHostVerifier class just calls `verify_software`
on its target. The purpose of the class is merely to provide
a temporary call for code that hasn't been split out to its
own verifiers. But, really, that code should be split out,
and the LegacyHostVerifier class should be deleted.
Here's the remaining work:
* Fix bug 596131 (create a free space verifier).
+ Consider also adding RepairAction classes to 'rm -rf'
well-known sources of excess as a faster solution
than power wash.
* Create a verifier for firmware status check.
+ This also means fixing the TODO for the firmware repair
check in cros_repair.py
* Create a verifier to check the system-status job.
* Create a verifier to check that update_engine works. This
verifier should depend on the system-status verifier.
* Create a verifier for the cros-version label check.
,
Aug 2 2016
,
Dec 2 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/1bf22a35315b59f202a1e35bd653656d9b25cc94 commit 1bf22a35315b59f202a1e35bd653656d9b25cc94 Author: Richard Barnette <jrbarnette@chromium.org> Date: Sat Nov 19 00:14:31 2016 [autotest] Extract firmware verification into a verifier. This moves code for firmware verification from the legacy 'cros' verifier into its own separate verifier, and changes the firmware repair action to trigger on that verifier, instead of the 'cros' verifier. BUG=chromium:633345 TEST=Invoke the new verifier manually at the python CLI Change-Id: I41b9ea9b62124c56cfbf6037dd9bbec9b6c7fa61 Reviewed-on: https://chromium-review.googlesource.com/413069 Commit-Ready: Richard Barnette <jrbarnette@chromium.org> Tested-by: Richard Barnette <jrbarnette@chromium.org> Reviewed-by: Xixuan Wu <xixuan@chromium.org> [modify] https://crrev.com/1bf22a35315b59f202a1e35bd653656d9b25cc94/server/hosts/cros_host.py [modify] https://crrev.com/1bf22a35315b59f202a1e35bd653656d9b25cc94/server/hosts/cros_repair.py [modify] https://crrev.com/1bf22a35315b59f202a1e35bd653656d9b25cc94/server/hosts/cros_firmware.py
,
Dec 11 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 8 2018
Hi, this bug has not been updated recently and remains untriaged. Please acknowledge the bug and provide status within two weeks (6/22/2018), or the bug will be closed. Thank you.
,
Jun 12 2018
Regarding the identified work: > * Fix bug 596131 (create a free space verifier). > + Consider also adding RepairAction classes to 'rm -rf' > well-known sources of excess as a faster solution > than power wash. This is relevant. > * Create a verifier for firmware status check. > + This also means fixing the TODO for the firmware repair > check in cros_repair.py This has already been separated. > * Create a verifier to check the system-status job. > * Create a verifier to check that update_engine works. This > verifier should depend on the system-status verifier. > * Create a verifier for the cros-version label check. These three are of dubious value. * In recent history, the cros-version label check seems to have found only spurious errors. Arguably, though, this could protect from a DUT that gets borrowed for a manual test and re-installed. * Few tests will fail if update_engine isn't working, and provisioning already checks that this starts, so re-checking in verify is less useful. * The system-status job might be worth checking: If it fails to start it could indicate some important service isn't available, which could cause test failures. OTOH, specific test failures might be more valuable than a verification failure. |
||||
►
Sign in to add a comment |
||||
Comment 1 by jrbarnette@chromium.org
, Aug 1 2016