Added a timeout to stop requests.get hanging on platforms with no internet

[wilbertcs]

When running our AT's ,we import 'IrisTest' from 'iris.tests'. Our tests run on the HPC which has restricted or no internet access, which causes the 'requests.get' call to hang indefinitely.
In this PR, I've added a 1 second timeout to the 'requests.get' call to stop the call hanging.

Testing on the HPC:
The following call will return with a 'ConnectTimeoutError' on the HPC :
'

import requests
try:
... requests.get('https://github.com/scitools/iris', timeout=1.0)
... except:
... print('Timed out')
...
Timed out

'
which would allow the code to continue....

However , without the timeout the following call will hang indefinitely and has to be stopped, in this case, with a keyboardInterrupt:
`

requests.get('https://github.com/scitools/iris')
^CTraceback (most recent call last):
File "", line 1, in
File "/criticalA/scitools/environments/experimental/2019_02_18-1/lib/python3.6/site-packages/requests/api.py", line 75, in get
return request('get', url, params=params, **kwargs)
File "/criticalA/scitools/environments/experimental/2019_02_18-1/lib/python3.6/site-packages/requests/api.py", line 60, in request
return session.request(method=method, url=url, **kwargs)
File "/criticalA/scitools/environments/experimental/2019_02_18-1/lib/python3.6/site-packages/requests/sessions.py", line 533, in request
resp = self.send(prep, **send_kwargs)
File "/criticalA/scitools/environments/experimental/2019_02_18-1/lib/python3.6/site-packages/requests/sessions.py", line 646, in send
r = adapter.send(request, **kwargs)
File "/criticalA/scitools/environments/experimental/2019_02_18-1/lib/python3.6/site-packages/requests/adapters.py", line 449, in send
timeout=timeout
File "/criticalA/scitools/environments/experimental/2019_02_18-1/lib/python3.6/site-packages/urllib3/connectionpool.py", line 600, in urlopen
chunked=chunked)
File "/criticalA/scitools/environments/experimental/2019_02_18-1/lib/python3.6/site-packages/urllib3/connectionpool.py", line 343, in _make_request
self._validate_conn(conn)
File "/criticalA/scitools/environments/experimental/2019_02_18-1/lib/python3.6/site-packages/urllib3/connectionpool.py", line 839, in _validate_conn
conn.connect()
File "/criticalA/scitools/environments/experimental/2019_02_18-1/lib/python3.6/site-packages/urllib3/connection.py", line 301, in connect
conn = self._new_conn()
File "/criticalA/scitools/environments/experimental/2019_02_18-1/lib/python3.6/site-packages/urllib3/connection.py", line 159, in _new_conn
(self._dns_host, self.port), self.timeout, **extra_kw)
File "/criticalA/scitools/environments/experimental/2019_02_18-1/lib/python3.6/site-packages/urllib3/util/connection.py", line 70, in create_connection
sock.connect(sa)
KeyboardInterrupt

`

[lbdreyer]

Thanks for this @wilbertcs ! A really helpful addition!

The SciTools-CLA-checker is failing as we don't have you on our list of known and approved contributors. Could you fill in this form https://scitools.org.uk/cla/v4/form which should (after a couple hours or so) automatically update the CLA-checker to pass

[lbdreyer]

"on the HPC" makes the comment a bit too specific to the Met Office. Could you make it more general and say "a platform with no internet access"

So something like:

# Added a timeout to stop the call to requests.get hanging when running
# on a platform which has restricted/ no internet access.

[pp-mo]

Sorry to barge in, but just a couple of queries ..

• I think I understood that this is known to be Python3-specific problem ?
  Are we sure of that / why that is / it is definitely appropriate to add an explicit timeout here (and fix does not belong here)
• are we clear that 1 second is actually long enough ? It sounds possibly a bit short to me.

[wilbertcs]

No problem i'll update the message.
When testing this I found the cut off point to be about 0.6 seconds so chose 1 second as a timeout, however any advice on a more appropriate fix / timeout value would be appreciated.

[pp-mo]

Our Travis runs don't always run with good resourcing, we frequently get test run timeouts where something that "normally" takes 5-6minutes stretches to 10-15.
So I'd say it's handy to be generous, maybe 5-10 seconds ?
I guess the downside of an over-early test failure would be, for us, if it silently misses a test which it should have run, and something unintended might slip through.

[wilbertcs]

Changed timeout to 10 seconds.

[wilbertcs]

I've completed the CLA form as requested.

[pp-mo]

I don't see the CLA checker.
Perhaps it just needs to re-run.
Try pushing a meaningless commit or amended commit message?

[ajdawson]

The commits are not identified as being owned by the user who signed the CLA. If these commits are yours @wilbertcs then you need to add the email address they were committed under to your Github account (Settings -> Emails) so that Github (and hence the CLA checker) will know they are yours.

[mo-g]

Is it worth adding a flag constant (FASTGET=1..?) for this, or being a test only, is that adding complexity for the sake of it - with no real need to worry about the slowdown?

[lbdreyer]

Hi @mo-g! 👋 Good to hear from you :)

I do want to get this merged before the 2.2.1 release, and for simplicity sake I think we should leave it as it is.

But if it does prove to be an issue we could add it in a follow up PR

[lbdreyer]

@wilbertcs I'm not sure why the stickler-ci job isn't running.
I'm going to close and re-open the PR but if that doesn't work I will just merge this in as the sticker ci job should just pass.

[mo-g]

Hi @mo-g! wave Good to hear from you :)

You too! :)

[lbdreyer]

Thanks for this @wilbertcs !

This will be available in the Iris 2.2.1 release, which I hope to cut in the next couple of weeks