1037777 - [steeplechase] verify if signaling server URL is reachable

Status: NEW

(Testing :: General, defect)

Description

[Nils Ohlmeier [:drno]]

If you provide an incorrect client IP to steeplechase it starts and prints this message:
  steeplechase INFO | Pushing app to Client 1...
Although it is obviously not connected to Client 1 at all.

Steeplechase should detect that it can not connect to the wrong Client 1 and exit with an error instead.

Comment 1

[Martijn Wargers (dead)]

What I get after trying to connect to the wrong IP:
mwargers@ubuntu:~$ /usr/bin/env python ~/steeplechase/steeplechase/runsteeplechase.py --binary ~/firefox/firefox --specialpowers-path ~/tests/steeplechase/specialpowers --prefs-file ~/tests/steeplechase/prefs_general.js --signalling-server 'http://xxx.xx.xx.xxx:8080/' --html-manifest steeplechase/sample_tests/manifest.ini --host1 xxx.xx.xx.xxx:20701 --host2 xxx.xx.xx.xxx:20701 --save-logs-to ~/logs/
Traceback (most recent call last):
  File "/home/mwargers/steeplechase/steeplechase/runsteeplechase.py", line 311, in <module>
    sys.exit(0 if main(sys.argv[1:]) else 1)
  File "/home/mwargers/steeplechase/steeplechase/runsteeplechase.py", line 238, in main
    dm1 = DeviceManagerSUT(host, port)
  File "/usr/local/lib/python2.7/dist-packages/mozdevice-0.37-py2.7.egg/mozdevice/devicemanagerSUT.py", line 49, in __init__
    self.getDeviceRoot()
  File "/usr/local/lib/python2.7/dist-packages/mozdevice-0.37-py2.7.egg/mozdevice/devicemanagerSUT.py", line 704, in getDeviceRoot
    data = self._runCmds([{ 'cmd': 'testroot' }])
  File "/usr/local/lib/python2.7/dist-packages/mozdevice-0.37-py2.7.egg/mozdevice/devicemanagerSUT.py", line 154, in _runCmds
    self._sendCmds(cmdlist, outputfile, timeout, retryLimit=retryLimit)
  File "/usr/local/lib/python2.7/dist-packages/mozdevice-0.37-py2.7.egg/mozdevice/devicemanagerSUT.py", line 145, in _sendCmds
    raise DMError("Remote Device Error: unable to connect to %s after %s attempts" % (self.host, retryLimit))
mozdevice.devicemanager.DMError: Remote Device Error: unable to connect to xxx.xx.xx.xxx after 5 attempts
mwargers@ubuntu:~$

Comment 2

[Nils Ohlmeier [:drno]]

Looks like in your case the "wrong" IP address was in use by some device. In my case the "wrong" IP address was not in use at all on the network.

Comment 3

[Martijn Wargers (dead)]

I also get the result from comment 1 with complete bogus IP addresses for host1 and host2:
mwargers@ubuntu:~$ /usr/bin/env python ~/steeplechase/steeplechase/runsteeplechase.py --binary ~/firefox/firefox --specialpowers-path ~/tests/steeplechase/specialpowers --prefs-file ~/tests/steeplechase/prefs_general.js --signalling-server 'http://xxx.xx.xx.xxx:8080/' --html-manifest steeplechase/sample_tests/manifest.ini --host1 bogus --host2 bogus --save-logs-to ~/logs/

Comment 4

[Martijn Wargers (dead)]

Attachment: 1037777.diff

This fixes a similar issue when it can't connect to the signalling server, but I guess this issue is about when it can't connect to the negatus clients.

Comment 5

[Nils Ohlmeier [:drno]]

Comment on attachment 8461146 [details] [diff] [review]
1037777.diff

Review of attachment 8461146 [details] [diff] [review]:
-----------------------------------------------------------------

This basically tries to connect to the simple signaling server before steeplechase actually starts running, right?
Looks good to me.

Comment 6

[Nils Ohlmeier [:drno]]

If it is not reproducible lets close this ticket.

Comment 7

[Martijn Wargers (dead)]

Comment on attachment 8461146 [details] [diff] [review]
1037777.diff

(In reply to Nils Ohlmeier [:drno] from comment #5)
> Review of attachment 8461146 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This basically tries to connect to the simple signaling server before
> steeplechase actually starts running, right?
> Looks good to me.

Yes. The "pushing client" stuff takes a long time, so it would be nice to know beforehand if one can connect to the signalling server.
Ted, do you think this is ok? Can you then push it to your repo?

Comment 8

[Martijn Wargers (dead)]

(In reply to Nils Ohlmeier [:drno] from comment #6)
> If it is not reproducible lets close this ticket.

It's not reproducible to me, but I've know attached a patch to this bug that fixes something unrelated. I guess we could morph it to that issue.

Comment 9

[(not currently active) Ted Mielczarek]

Comment on attachment 8461146 [details] [diff] [review]
1037777.diff

Review of attachment 8461146 [details] [diff] [review]:
-----------------------------------------------------------------

This is fine, but I don't think it fixes the issue as reported, right? (Bad client IPs.)

Comment 10

[Martijn Wargers (dead)]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #9)
> This is fine, but I don't think it fixes the issue as reported, right? (Bad
> client IPs.)

That is correct, but I couldn't reproduce it and Nils was fine with closing this bug (I'm not sure he could still reproduce this).

Comment 11

[Nils Ohlmeier [:drno]]

As Syd ran into the problem the patch here solves I think it would make sense to land this. I guess we should convert this into a GitHub PR.