Bug 749625

Summary: Add configurable connection timeout for Aviary Suds clients [RFE]
Product: Red Hat Enterprise MRG Reporter: Trevor McKay <tmckay>
Component: cuminAssignee: grid-maint-list <grid-maint-list>
Status: CLOSED WONTFIX QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: low Docs Contact:
Priority: low    
Version: DevelopmentCC: matt, mkudlej, pmackinn, sgraf
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-26 20:23:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Trevor McKay 2011-10-27 17:50:46 UTC 
Description of problem:

Default timeout for a bad URL is 90 seconds.  See if we can get a handle on the urllib2 "timeout" parameter and a config to control how soon Cumin connections to Aviary services will timeout.

Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1.  Configure Cumin to talk to Aviary successfully with ssl.
2.  Change aviary-job-servers and/or aviary-query-servers addresses to use "http:" instead of "https:" as the scheme value.
3.  Try to do an aviary operation, like drilling into a submission.
  
Actual results:

Cumin will wait for 90 seconds saying "Loading..." before reporting an error.

Expected results:

If we have a configurable timeout, we should be able to set the timeout to something small (10 or 15 seconds) and report failure much earlier.

Additional info:

Tried a quick change to make this work in the development version, but there is something more complex going on.  Independent tests by pmackinn with standalone scripts show it working.  Deferring.
Comment 1 Trevor McKay 2011-10-27 20:33:58 UTC 
Implementation note,

figured out how to set this in Cumin with custom transports, earlier problems have to do with the semantics of linked option sets between Clients and Transports in Suds.  Essentially, you really don't want to do the following because the undefined ordering of dictionary iterations can lead to the timeout being applied before the transport is updated, which won't work:

c = Client(url, transport=MyTransport, timeout=15)


Instead you want to do something like one of these

With default transport, just set the timeout:

c = Client(url, timeout=15)

or

c = Client(url)
c.setoptions(timeout=15)


With a custom transport, one of the following:

c = Client(url, transport=MyTransport(timeout=15))

or

c = Client(url, transport=MyTransport)
c.setoptions(timeout=15)

or maybe this if the client already exists...

t = MyTransport(timeout=15)
c.setoptions(transport=t)

or even this to preserve an existing timeout

t = MyTransport(timeout=c.options.timeout)
c.setoptions(transport=t)
Comment 3 Anne-Louise Tangring 2016-05-26 20:23:29 UTC 
MRG-Grid is in maintenance and only customer escalations will be considered. This issue can be reopened if a customer escalation associated with it occurs.