test_session_client_debug_logger DiscoveryFailure: Invalid Response on queens

Bug #1749244 reported by Corey Bryant on 2018-02-13
This bug affects 1 person
Affects Status Importance Assigned to Milestone
python-cinderclient (Ubuntu)

Bug Description

'tox -e py27' results in a failure for test_session_client_debug_logger:
keystoneauth1.exceptions.discovery.DiscoveryFailure: Invalid Response - Bad version data returned: <html><body><script>window.location="http://dnserr...

Full traceback: https://paste.ubuntu.com/p/gzb9pYN9g7/

Corey Bryant (corey.bryant) wrote :

This is occurring on stable/queens on commit 49c50dfa2eeed490ca984c07cdc011e925233ec3.

Changed in python-cinderclient (Ubuntu):
status: New → Triaged
importance: Undecided → High
Corey Bryant (corey.bryant) wrote :

This test fails for py2 and py3.

Rajat Dhasmana (whoami-rajat) wrote :

It's passing on my env.

Ran: 1 tests in 0.0000 sec.
 - Passed: 1
 - Skipped: 0
 - Expected Fail: 0
 - Unexpected Success: 0
 - Failed: 0
Sum of execute time for each test: 0.2196 sec.

Worker Balance
 - Worker 0 (1 tests) => 0:00:00.219633
py27 runtests: commands[2] | stestr slowest
Test id Runtime (s)
----------------------------------------------------------------------------- -----------
cinderclient.tests.unit.test_shell.ShellTest.test_session_client_debug_logger 0.220
______________________________________________________________ summary _______________________________________________________________
  py27: commands succeeded
  congratulations :)

Corey Bryant (corey.bryant) wrote :

Hmm that's interesting. I just hit it on master on Ubuntu Cosmic. Maybe it's a difference in the underlying distro.

LIU Yulong (dragon889) wrote :
Changed in python-cinderclient:
status: New → Confirmed
Markus Hentsch (mhen) wrote :

We ran into the same issue in our infrastructure. Valuable hint was the following entry in the debug output of tox: "GET http://no.where/v2.0" - which resulted in a 200 OK response. On a local system this was not the case as "no.where" should not resolve to anything and the unit test actually expects an error instead of a successful connection here.

However, in our case a DNS server was the culprit, which still resolved the name to an internal address. When executing "dig http://no.where/v2.0" on the system running the unit tests, we saw a DNS answer. Removing the DNS resolution for "no.where" solved the issue.

So, maybe check the DNS resolution on your CI systems!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers