This seems to be similar, or the same problem as in https://bugs.launchpad.net/tripleo/+bug/1731063
However, the package ovsdbapp used is the same that should have the fix.
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/tempest/common/utils/__init__.py", line 89, in wrapper
return f(*func_args, **func_kwargs)
File "/usr/lib/python2.7/site-packages/tempest/scenario/test_volume_boot_pattern.py", line 112, in test_volume_boot_pattern
private_key=keypair['private_key'])
File "/usr/lib/python2.7/site-packages/tempest/scenario/manager.py", line 609, in create_timestamp
private_key=private_key)
File "/usr/lib/python2.7/site-packages/tempest/scenario/manager.py", line 356, in get_remote_client
linux_client.validate_authentication()
File "/usr/lib/python2.7/site-packages/tempest/lib/common/utils/linux/remote_client.py", line 57, in wrapper
six.reraise(*original_exception)
File "/usr/lib/python2.7/site-packages/tempest/lib/common/utils/linux/remote_client.py", line 30, in wrapper
return function(self, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/tempest/lib/common/utils/linux/remote_client.py", line 113, in validate_authentication
self.ssh_client.test_connection_auth()
File "/usr/lib/python2.7/site-packages/tempest/lib/common/ssh.py", line 207, in test_connection_auth
connection = self._get_ssh_connection()
File "/usr/lib/python2.7/site-packages/tempest/lib/common/ssh.py", line 121, in _get_ssh_connection
password=self.password)
tempest.lib.exceptions.SSHTimeout: Connection to the 192.168.24.108 via SSH timed out.
User: cirros, Password: None
LOGS:
https://logs.rdoproject.org/openstack-periodic/periodic-tripleo-ci-centos-7-multinode-1ctlr-featureset016-master/b09f8f0/tempest.html.gz
Also notice this is only failing in multinode jobs, the ovb jobs using the same hash are not being affected:
https://logs.rdoproject.org/openstack-periodic/periodic-tripleo-ci-centos-7-ovb-1ctlr_1comp-featureset020-master/33d447c/tempest.html.gz
I looked at this with Ihar for a while today and didn't find any smoking gun in the log files.
There are a few things we'd need to do debug this further from the neutron side, assuming it's a networking issue:
1. Stop the system under test when this fails so we can login and look around.
2. Make sure we have the console log of the instance(s). If this isn't doable via some setting we need to look at something like https:/
3. Log haproxy and metadata agent serviced requests. The haproxy conf file shows it should log to /dev/log, which is exposed in the container, but I couldn't find any evidence of logging anywhere. The metadata agent does not over-ride debug level like other agents, should set "debug = True" in metadata_agent.ini
In the meantime it might be worth skipping the test until we can gather additional information if it is critical.