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

Issue 699211 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Aug 22
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Add a testbed test to the CQ

Project Member Reported by pprabhu@chromium.org, Mar 7 2017

Issue description

Probably via moblab's suite?

I'm making changes to the way host objects are used and have had to revert CLs mutiple times now because I didn't test testbed locally. Testing changes to testbed locally is hard. Can I haz some CQ coverage?

What would be involved?

See  issue 699188 . The problem itself was trivial (I had a fix in < 10 minutes), but this was blocking a test_push which was blocking a push needed to fix another P-0 in prod. So, I chose to revert my CL instead of landing the trivial fix. I really don't want to do this. :(
 

Comment 1 by sbasi@chromium.org, Mar 7 2017

Cc: haoweiw@chromium.org
What is involved is adding multiple homo-genus android devices to each moblab setup and a version of run_suite to look up their serials, add them to the db and run the basic testbed suite.
Cc: akes...@chromium.org
This is seriously slowing me down.
Owner: sbasi@chromium.org
Cc: dshi@chromium.org kevcheng@chromium.org
q1) Can this be made reliable enough for the CQ?
q2) Can this coverage be gained by unit tests or virtualization?
q3) If the answer to above 2 is no, then does this even belong in the push to prod test?
Re #4.q3) In the specific case of  issue 699188 , test_push did it's job. Without the test in the push to prod test, I would have broken android testing in prod...

Comment 6 by sbasi@chromium.org, Mar 7 2017

Cc: krisr@chromium.org bpeake@chromium.org
The reason we have this in test_push is to prevent outages, which is significantly better having nothing at all.

q2) Adding unittests is a good first step but I think a lot of the DB/RPC interactions may have to be mocked out and not have covered this. But we can investigate this.

q1) We already have a fair amount of flake with Moblab testing... this adds more complexity say should the android test devices get stuck or power down, etc.


The main reason there was a forced revert rather than wait for a simple fix was b/c there was another big outage due to the lack of AFE UI testing in the CQ and test_push. Do we plan to address that as well?

Comment 7 by sbasi@chromium.org, Mar 7 2017

I write provide a functional end-to-end MobLab+Testbed integration test.

Whether or not it will be ran in the lab or used just locally at one's desk for verification is still open for debate.
Labels: -current-issue
Labels: akeshet-pending-downgrade
ChromeOS Infra P1 Bugscrub.

P1 Bugs in this component should be important enough to get weekly status updates.

Is this already fixed?  -> Fixed
Is this no longer relevant? -> Archived or WontFix
Is this not a P1, based on go/chromeos-infra-bug-slo rubric? -> lower priority.
Is this a Feature Request rather than a bug? Type -> Feature
Is this missing important information or scope needed to decide how to proceed? -> Ask question on bug, possibly reassign.
Does this bug have the wrong owner? -> reassign.

Bugs that remain in this state next week will be downgraded to P2.
Labels: -akeshet-pending-downgrade Pri-2
ChromeOS Infra P1 Bugscrub.

Issue untouched in a week after previous message. Downgrading to P2.
Hi, this bug has not been updated recently. Please acknowledge the bug and provide status within two weeks (6/22/2018), or the bug will be archived. Thank you.
Status: Assigned (was: Available)
Status: WontFix (was: Assigned)

Sign in to add a comment