| 6358168009dad043ff738fb1cdfb31e2ed2a2ba6 |
|
23-Mar-2017 |
Aviv Keshet <akeshet@chromium.org> |
autotest: fix shard_client_integration_test
BUG=chromium:704400
TEST=shard_client_integration_test
Change-Id: I67b55b410270b27158b449088272bd2294e73951
Reviewed-on: https://chromium-review.googlesource.com/457928
Commit-Ready: Aviv Keshet <akeshet@chromium.org>
Tested-by: Aviv Keshet <akeshet@chromium.org>
Reviewed-by: Dan Shi <dshi@google.com>
/external/autotest/scheduler/shard/shard_client_integration_tests.py
|
| 67ad67d564fd605dc0ac3671b1620a601cfc6c90 |
|
29-Jun-2016 |
Justin Giorgi <jgiorgi@google.com> |
[autotest] Removed copy of unittest library.
All tests still pass with the standard unittest library.
BUG=None
TEST=Executed utils/unittest_suite.py locally
Change-Id: I86f7e2884282bca0fcb240fe2f70c4adb71f8ddf
Reviewed-on: https://chromium-review.googlesource.com/357330
Commit-Ready: Justin Giorgi <jgiorgi@google.com>
Tested-by: Justin Giorgi <jgiorgi@google.com>
Reviewed-by: Richard Barnette <jrbarnette@google.com>
Reviewed-by: Simran Basi <sbasi@chromium.org>
/external/autotest/scheduler/shard/shard_client_integration_tests.py
|
| af5166418be945356238768cfc8226f3c2aa7138 |
|
13-Dec-2014 |
Prashanth Balasubramanian <beeps@google.com> |
[autotest] Delete shard user if it differs from master.
For most models the shard starts off with an empty database
and copies over records from the master. There is one exception,
afe_users, this is because users are proactively created when
someone navigates to the frontend. So even though we start
off with a clean afe_users table the `debug_user` will be
inserted the first time anyone visits the shard frontend. The id
of this record can be different from the id on the master.
To avoid this race, before saving any user record for the first
time check if a matching user already exists (matching id or login)
and simply delete that user before saving the new one.
TEST=Ran suites on shard.
BUG=chromium:423225
DEPLOY=apache
Change-Id: Ibe1d452bbba037c88e6525c749f27a2f1f5ca2c3
Reviewed-on: https://chromium-review.googlesource.com/235533
Tested-by: Prashanth B <beeps@chromium.org>
Reviewed-by: Dan Shi <dshi@chromium.org>
Commit-Queue: Prashanth B <beeps@chromium.org>
Trybot-Ready: Prashanth B <beeps@chromium.org>
/external/autotest/scheduler/shard/shard_client_integration_tests.py
|
| 22dd226625255110c079e979113dcda1f4fa5ea8 |
|
29-Nov-2014 |
Prashanth Balasubramanian <beeps@google.com> |
[autotest] Shard client resyncs conflicting jobs.
There is currently a race in the shard_client, described thus:
* scheduler marks job 1 complete
* shard heartbeat doesn't include job 1 in packet
* scheduler marks job 1 with shard_id = NULL (for upload)
* master replies with 'Hey job 1 is Queued but you say it
isn't running'
* shard serializes the fks of job1 sent by master, over
writing the NULL shard_id
=> Job1 is never synced back to the master
This cl fixes this race by:
1. The shard client continues to declare a job as incomplete till
the scheduler has update the shard_id to NULL. In the above
example, the second step won't happen.
2. If the shard_client notices any disagreement between the complete
bits of jobs in the local db and the 'new' jobs sent from the
master, it re-marks the job for upload by setting shard_id=NULL.
In the above example this would happen after the last step,
forcing the next heartbeat to pick up the job.
The cl also adds some important stats and logging to help debug
issues in production.
TEST=Ran suites via puppylab, unittests.
BUG=chromium:423225,chromium:425347
DEPLOY=scheduler
Change-Id: Ib35b193681b187e3745a4678778dbeba77fe83e5
Reviewed-on: https://chromium-review.googlesource.com/232193
Tested-by: Prashanth B <beeps@chromium.org>
Reviewed-by: Fang Deng <fdeng@chromium.org>
Commit-Queue: Prashanth B <beeps@chromium.org>
/external/autotest/scheduler/shard/shard_client_integration_tests.py
|