Reland "Allow multiple devices on bisects hosts "

Reland "Allow multiple devices on bisects hosts "

old issue: https://codereview.chromium.org/2045043002/ 
This CL aims to fix the naming error in the original issue
and add some simulation tests to prevent similar errors from
happening.

Committed: https://chromium.googlesource.com/chromium/tools/build/+/b9bf5e668a4a35d646e067672150fb3999b98059

[Ziqi Xiong, 2016-06-30 17:36:54]

Description was changed from

==========
Redo bisect test after step failure if multuple devices are connected to host.

Right now, when an android device connected to a bisect linux host goes offline,
we still send bisects to that host, and the bisects fail.
So the device needs to be fixed with extremely urgent priority.
This CL aims to allow multiple devices to be connected to a linux host and if a
device failed,
the job would be retried with a device that is still working.
BUG=
==========

to

==========
Redo bisect test after step failure if multiple devices are connected to host.

Right now, when an android device connected to a bisect linux host goes offline,
we still send bisects to that host, and the bisects fail.
So the device needs to be fixed with extremely urgent priority.
This CL aims to allow multiple devices to be connected to a linux host and if a
device failed,
the job would be retried with a device that is still working.
BUG=
==========

[Ziqi Xiong, 2016-06-30 17:42:46]

zxiong@google.com changed reviewers:
+ robertocn@chromium.org, robertocn@google.com

[Ziqi Xiong, 2016-06-30 17:42:46]

The previous CL on multiple devices switch has been reverted. This is the new CL
that fixes the caused error.

[Ziqi Xiong, 2016-06-30 21:35:12]

Description was changed from

==========
Redo bisect test after step failure if multiple devices are connected to host.

Right now, when an android device connected to a bisect linux host goes offline,
we still send bisects to that host, and the bisects fail.
So the device needs to be fixed with extremely urgent priority.
This CL aims to allow multiple devices to be connected to a linux host and if a
device failed,
the job would be retried with a device that is still working.
BUG=
==========

to

==========
Original issue: https://codereview.chromium.org/2045043002/

android_chromium.api.devices() should be changed to 
android_chromium.api.devices.

BUG=
==========

[Ziqi Xiong, 2016-07-07 01:44:49]

zxiong@google.com changed reviewers:
+ dtu@chromium.org

[Ziqi Xiong, 2016-07-13 00:36:34]

Description was changed from

==========
Original issue: https://codereview.chromium.org/2045043002/

android_chromium.api.devices() should be changed to 
android_chromium.api.devices.

BUG=
==========

to

==========
Reland "Redo bisect test after step failure if multiple devices are connected to
host". 
old issue: https://codereview.chromium.org/2045043002/ 
This CL aims to fix the naming error in the original issue and add some
simulation tests to prevent similar errors from
happening. 
BUG=
==========

[Ziqi Xiong, 2016-07-13 00:38:36]

Description was changed from

==========
Reland "Redo bisect test after step failure if multiple devices are connected to
host". 
old issue: https://codereview.chromium.org/2045043002/ 
This CL aims to fix the naming error in the original issue and add some
simulation tests to prevent similar errors from
happening. 
BUG=
==========

to

==========
Reland "Redo bisect test after step failure if multiple devices are connected to
host". 
old issue: https://codereview.chromium.org/2045043002/ 
This CL aims to fix the naming error in the original issue
 and add some simulation tests to prevent similar errors from
happening. 
BUG=
==========

[Ziqi Xiong, 2016-07-13 00:38:46]

Description was changed from

==========
Reland "Redo bisect test after step failure if multiple devices are connected to
host". 
old issue: https://codereview.chromium.org/2045043002/ 
This CL aims to fix the naming error in the original issue
 and add some simulation tests to prevent similar errors from
happening. 
BUG=
==========

to

==========
Reland "Redo bisect test after step failure if multiple devices are connected to
host". 
old issue: https://codereview.chromium.org/2045043002/ 
This CL aims to fix the naming error in the original issue
and add some simulation tests to prevent similar errors from
happening. 
BUG=
==========

[Ziqi Xiong, 2016-07-13 00:40:27]

zxiong@google.com changed reviewers:
+ dtu@google.com, sullivan@chromium.org
- dtu@chromium.org

[Ziqi Xiong, 2016-07-13 00:40:28]

I am currently working on this CL to reland my code on bisect device switch.

[Ziqi Xiong, 2016-07-13 00:41:03]

zxiong@google.com changed reviewers:
+ dtu@chromium.org
- dtu@google.com

[Ziqi Xiong, 2016-07-14 17:13:21]

Hi,

I have included some tests that simulate cases when:
(1) test device works on the first try
(2) no device is connected
(3) test fails but not because of disconnection
(4) test fails because test device is disconnected and there is an alternative
device connected
Let me know if I missed any test cases. Thanks!

[RobertoCN, 2016-07-14 23:46:03]

lgtm

https://codereview.chromium.org/2119483003/diff/130001/scripts/slave/recipes/...
File scripts/slave/recipes/bisection/android_bisect.py (right):

https://codereview.chromium.org/2119483003/diff/130001/scripts/slave/recipes/...
scripts/slave/recipes/bisection/android_bisect.py:587: api.step_data('Post
bisect results', retcode=1) +
# Simulating disconnect by raising failure and changing the output of
multiple_device_status

[Ziqi Xiong, 2016-07-15 00:44:36]

The CQ bit was checked by zxiong@google.com

[Ziqi Xiong, 2016-07-15 00:44:37]

The patchset sent to the CQ was uploaded after l-g-t-m from
robertocn@chromium.org
Link to the patchset: https://codereview.chromium.org/2119483003/#ps150001
(title: "Add comment to simulation test")

[commit-bot: I haz the power, 2016-07-15 00:44:48]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ziqi Xiong, 2016-07-15 00:46:41]

The CQ bit was unchecked by zxiong@google.com

[Ziqi Xiong, 2016-07-15 01:16:13]

zxiong@google.com changed reviewers:
+ jbudorick@chromium.org

[Ziqi Xiong, 2016-07-15 01:18:10]

zxiong@google.com changed reviewers:
- dtu@chromium.org, robertocn@chromium.org, robertocn@google.com,
sullivan@chromium.org

[Ziqi Xiong, 2016-07-15 01:18:11]

Hi John, I uploaded a CL that has a small change to chromium_android recipe
module. Let me know if that looks good to you!

[Ziqi Xiong, 2016-07-15 01:19:22]

zxiong@google.com changed reviewers:
+ dtu@chromium.org, robertocn@chromium.org, sullivan@chromium.org

[jbudorick, 2016-07-15 01:23:19]

I have concerns about this.

https://codereview.chromium.org/2119483003/diff/150001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/chromium_android/api.py (right):

https://codereview.chromium.org/2119483003/diff/150001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/chromium_android/api.py:25:
self._multiple_device_test = False
O_O

https://codereview.chromium.org/2119483003/diff/150001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/chromium_android/api.py:398: def
device_status(self,  **kwargs):
nit: no extra space

https://codereview.chromium.org/2119483003/diff/150001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/chromium_android/api.py:409: device_step_name =
'device_status'
Why are you optionally changing the step name?

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right):

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:43: perform_bisect(api,
**flags)
o_o

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:51:
api.m.chromium_android.device_status_check()
Use device_status now.

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:55: def
_pick_available_device(api, connected_devices):
This is basically reimplementing the blacklist that we use elsewhere
(https://github.com/catapult-project/catapult/blob/master/devil/docs/device_bl...).
I'd strongly prefer if we use that mechanism rather than reinventing it.

[Ziqi Xiong, 2016-07-15 01:36:06]

https://codereview.chromium.org/2119483003/diff/150001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/chromium_android/api.py (right):

https://codereview.chromium.org/2119483003/diff/150001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/chromium_android/api.py:409: device_step_name =
'device_status'
On 2016/07/15 01:23:18, jbudorick wrote:
> Why are you optionally changing the step name?

I thought it was easier to feed step data and made the test more readable in
that way when I wrote simulation tests. But yeah you are right it isn't really
necessary

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right):

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:51:
api.m.chromium_android.device_status_check()
On 2016/07/15 01:23:19, jbudorick wrote:
> Use device_status now.

Done.

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:55: def
_pick_available_device(api, connected_devices):
On 2016/07/15 01:23:19, jbudorick wrote:
> This is basically reimplementing the blacklist that we use elsewhere
>
(https://github.com/catapult-project/catapult/blob/master/devil/docs/device_bl...).
> I'd strongly prefer if we use that mechanism rather than reinventing it.

Sure, I will use blacklist instead. Thanks for letting me know!

[jbudorick, 2016-07-15 02:51:41]

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right):

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:55: def
_pick_available_device(api, connected_devices):
On 2016/07/15 01:36:06, Ziqi Xiong wrote:
> On 2016/07/15 01:23:19, jbudorick wrote:
> > This is basically reimplementing the blacklist that we use elsewhere
> >
>
(https://github.com/catapult-project/catapult/blob/master/devil/docs/device_bl...).
> > I'd strongly prefer if we use that mechanism rather than reinventing it.
> 
> Sure, I will use blacklist instead. Thanks for letting me know!

Thought about this a bit more, and I think the blacklist is overly complicated
for this use case. What about looping through the devices & breaking out of the
loop on success? Something like this:

def perform_bisect(...):
  # you may have to do device_status here, I'm not sure if all recipes that use
perform_bisect
  # call it beforehand.

  for d in api.m.chromium_android.devices:
    # name subject to change
    perform_single_bisect(d, ...)
    return
  except api.m.step.StepFailure:
    pass

  raise api.m.step.StepFailure

def perform_single_bisect(device, ...):
  # body of try block above


?

[Ziqi Xiong, 2016-07-15 04:38:08]

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right):

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:55: def
_pick_available_device(api, connected_devices):
On 2016/07/15 02:51:41, jbudorick wrote:
> On 2016/07/15 01:36:06, Ziqi Xiong wrote:
> > On 2016/07/15 01:23:19, jbudorick wrote:
> > > This is basically reimplementing the blacklist that we use elsewhere
> > >
> >
>
(https://github.com/catapult-project/catapult/blob/master/devil/docs/device_bl...).
> > > I'd strongly prefer if we use that mechanism rather than reinventing it.
> > 
> > Sure, I will use blacklist instead. Thanks for letting me know!
> 
> Thought about this a bit more, and I think the blacklist is overly complicated
> for this use case. What about looping through the devices & breaking out of
the
> loop on success? Something like this:
> 
> def perform_bisect(...):
>   # you may have to do device_status here, I'm not sure if all recipes that
use
> perform_bisect
>   # call it beforehand.
> 
>   for d in api.m.chromium_android.devices:
>     # name subject to change
>     perform_single_bisect(d, ...)
>     return
>   except api.m.step.StepFailure:
>     pass
> 
>   raise api.m.step.StepFailure
> 
> def perform_single_bisect(device, ...):
>   # body of try block above
> 
> 
> ?

That's definitely less convoluted than the current implementation. My concern is
that it only checks chromium_android.devices once and then starts a long for
loop. One of available devices in the list may fail during the test run, or a
device that was not in the list may be back online, and the device list should
be updated, but in a for loop we can't really change the iterated list. Those
cases must be a really rare but I still feel a bit uneasy about that.

[Ziqi Xiong, 2016-07-15 19:14:35]

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right):

https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:55: def
_pick_available_device(api, connected_devices):
On 2016/07/15 02:51:41, jbudorick wrote:
> On 2016/07/15 01:36:06, Ziqi Xiong wrote:
> > On 2016/07/15 01:23:19, jbudorick wrote:
> > > This is basically reimplementing the blacklist that we use elsewhere
> > >
> >
>
(https://github.com/catapult-project/catapult/blob/master/devil/docs/device_bl...).
> > > I'd strongly prefer if we use that mechanism rather than reinventing it.
> > 
> > Sure, I will use blacklist instead. Thanks for letting me know!
> 
> Thought about this a bit more, and I think the blacklist is overly complicated
> for this use case. What about looping through the devices & breaking out of
the
> loop on success? Something like this:
> 
> def perform_bisect(...):
>   # you may have to do device_status here, I'm not sure if all recipes that
use
> perform_bisect
>   # call it beforehand.
> 
>   for d in api.m.chromium_android.devices:
>     # name subject to change
>     perform_single_bisect(d, ...)
>     return
>   except api.m.step.StepFailure:
>     pass
> 
>   raise api.m.step.StepFailure
> 
> def perform_single_bisect(device, ...):
>   # body of try block above
> 
> 
> ?

Done.

[jbudorick, 2016-07-15 19:18:11]

On 2016/07/15 04:38:08, Ziqi Xiong wrote:
>
https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
> File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right):
> 
>
https://codereview.chromium.org/2119483003/diff/160001/scripts/slave/recipe_m...
> scripts/slave/recipe_modules/auto_bisect/local_bisect.py:55: def
> _pick_available_device(api, connected_devices):
> On 2016/07/15 02:51:41, jbudorick wrote:
> > On 2016/07/15 01:36:06, Ziqi Xiong wrote:
> > > On 2016/07/15 01:23:19, jbudorick wrote:
> > > > This is basically reimplementing the blacklist that we use elsewhere
> > > >
> > >
> >
>
(https://github.com/catapult-project/catapult/blob/master/devil/docs/device_bl...).
> > > > I'd strongly prefer if we use that mechanism rather than reinventing it.
> > > 
> > > Sure, I will use blacklist instead. Thanks for letting me know!
> > 
> > Thought about this a bit more, and I think the blacklist is overly
complicated
> > for this use case. What about looping through the devices & breaking out of
> the
> > loop on success? Something like this:
> > 
> > def perform_bisect(...):
> >   # you may have to do device_status here, I'm not sure if all recipes that
> use
> > perform_bisect
> >   # call it beforehand.
> > 
> >   for d in api.m.chromium_android.devices:
> >     # name subject to change
> >     perform_single_bisect(d, ...)
> >     return
> >   except api.m.step.StepFailure:
> >     pass
> > 
> >   raise api.m.step.StepFailure
> > 
> > def perform_single_bisect(device, ...):
> >   # body of try block above
> > 
> > 
> > ?
> 
> That's definitely less convoluted than the current implementation. My concern
is
> that it only checks chromium_android.devices once and then starts a long for
> loop. One of available devices in the list may fail during the test run, or a
> device that was not in the list may be back online, and the device list should
> be updated, but in a for loop we can't really change the iterated list. Those
> cases must be a really rare but I still feel a bit uneasy about that.

Sorry, meant to address these:
 - If a device falls offline while we're not using it, then the step fails and
we try another one. (If a device falls offline while we are using it, the step
also fails, but the behavior there is unchanged.)
 - If a device comes back online during a run, we don't use it. This isn't
really a problem. (Also, the only way I can conceivably imagine this happening
is if a device is plugged in during a bisect.)

In both cases, an idle device changing state like this is exceedingly rare.

[jbudorick, 2016-07-15 19:20:16]

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right):

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:26: connected_devices =
_get_connected_devices(api)
This should no longer be here, right?

[Ziqi Xiong, 2016-07-15 19:23:58]

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right):

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:26: connected_devices =
_get_connected_devices(api)
On 2016/07/15 19:20:16, jbudorick wrote:
> This should no longer be here, right?

I think it should. The bisect should be redone
when  there is a step failure caused by tested
device disconnection. To see if the tested device
is disconnected, we need to do device_status again and
see if the tested device is missing from the list.

[jbudorick, 2016-07-15 19:31:23]

lgtm, though I suppose you no longer need my lgtm

Since you significantly changed this, you may want to get robertocn@'s approval
again.

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right):

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:26: connected_devices =
_get_connected_devices(api)
On 2016/07/15 19:23:58, Ziqi Xiong wrote:
> On 2016/07/15 19:20:16, jbudorick wrote:
> > This should no longer be here, right?
> 
> I think it should. The bisect should be redone
> when  there is a step failure caused by tested
> device disconnection. To see if the tested device
> is disconnected, we need to do device_status again and
> see if the tested device is missing from the list.

Oh, I see what you mean.

[RobertoCN, 2016-07-15 19:59:47]

I have a couple comments.

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right):

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:15: if
api.m.chromium.c.TARGET_PLATFORM == 'android':
Is this check necessary again? look at the if in line 11.

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:26: connected_devices =
_get_connected_devices(api)
Is there a way to check that one particular device is disconnected? It might
look a little cleaner.

Also, if running _get_connected_devices is necessary, store the result in other
variable, modifying the list you are iterating on may act strangely, and be hard
to debug.

[jbudorick, 2016-07-15 20:01:37]

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right):

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:26: connected_devices =
_get_connected_devices(api)
On 2016/07/15 19:59:47, RobertoCN wrote:
> Is there a way to check that one particular device is disconnected? It might
> look a little cleaner.
> 
> Also, if running _get_connected_devices is necessary, store the result in
other
> variable, modifying the list you are iterating on may act strangely, and be
hard
> to debug.

I tried this out locally (on sample code) and I don't think it affects the
iteration.

That said, I do agree that it makes things more confusing, so +1

[Ziqi Xiong, 2016-07-15 20:19:07]

Fix problems noted by robertocn

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
File scripts/slave/recipe_modules/auto_bisect/local_bisect.py (right):

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:15: if
api.m.chromium.c.TARGET_PLATFORM == 'android':
On 2016/07/15 19:59:47, RobertoCN wrote:
> Is this check necessary again? look at the if in line 11.

Done.

https://codereview.chromium.org/2119483003/diff/200001/scripts/slave/recipe_m...
scripts/slave/recipe_modules/auto_bisect/local_bisect.py:26: connected_devices =
_get_connected_devices(api)
On 2016/07/15 19:59:47, RobertoCN wrote:
> Is there a way to check that one particular device is disconnected? It might
> look a little cleaner.
> 
> Also, if running _get_connected_devices is necessary, store the result in
other
> variable, modifying the list you are iterating on may act strangely, and be
hard
> to debug.

Done.

[RobertoCN, 2016-07-15 22:56:46]

lgtm

[Ziqi Xiong, 2016-07-15 23:47:01]

Description was changed from

==========
Reland "Redo bisect test after step failure if multiple devices are connected to
host". 
old issue: https://codereview.chromium.org/2045043002/ 
This CL aims to fix the naming error in the original issue
and add some simulation tests to prevent similar errors from
happening. 
BUG=
==========

to

==========
Reland "Redo bisect test after step failure if multiple devices are connected to
host". 
old issue: https://codereview.chromium.org/2045043002/ 
This CL aims to fix the naming error in the original issue
and add some simulation tests to prevent similar errors from
happening.
==========

[Ziqi Xiong, 2016-07-15 23:47:09]

The CQ bit was checked by zxiong@google.com

[Ziqi Xiong, 2016-07-15 23:47:10]

The patchset sent to the CQ was uploaded after l-g-t-m from
jbudorick@chromium.org
Link to the patchset: https://codereview.chromium.org/2119483003/#ps220001
(title: "Remove irrelavant if statement, rename connected_devices variable")

[commit-bot: I haz the power, 2016-07-15 23:47:12]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-15 23:52:13]

Description was changed from

==========
Reland "Redo bisect test after step failure if multiple devices are connected to
host". 
old issue: https://codereview.chromium.org/2045043002/ 
This CL aims to fix the naming error in the original issue
and add some simulation tests to prevent similar errors from
happening.
==========

to

==========
Reland "Redo bisect test after step failure if multiple devices are connected to
host". 
old issue: https://codereview.chromium.org/2045043002/ 
This CL aims to fix the naming error in the original issue
and add some simulation tests to prevent similar errors from
happening.

Committed:
https://chromium.googlesource.com/chromium/tools/build/+/b9bf5e668a4a35d646e0...
==========

[commit-bot: I haz the power, 2016-07-15 23:52:14]

Committed patchset #16 (id:220001) as
https://chromium.googlesource.com/chromium/tools/build/+/b9bf5e668a4a35d646e0...

[Ziqi Xiong, 2016-08-02 20:21:19]

Description was changed from

==========
Reland "Redo bisect test after step failure if multiple devices are connected to
host". 
old issue: https://codereview.chromium.org/2045043002/ 
This CL aims to fix the naming error in the original issue
and add some simulation tests to prevent similar errors from
happening.

Committed:
https://chromium.googlesource.com/chromium/tools/build/+/b9bf5e668a4a35d646e0...
==========

to

==========
Reland "Allow multiple devices on bisects hosts "

old issue: https://codereview.chromium.org/2045043002/ 
This CL aims to fix the naming error in the original issue
and add some simulation tests to prevent similar errors from
happening.

Committed:
https://chromium.googlesource.com/chromium/tools/build/+/b9bf5e668a4a35d646e0...
==========