In recent tempest runs with custom guest image and OVS security groups, some tests in tempest.scenario.test_network_v6.TestGettingAddress fail: tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_dhcp6_stateless_from_os tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_multi_prefix_dhcpv6_stateless tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_slaac_from_os Same tests pass in other CI jobs Identical failure in test preparation, sample backtrace: Traceback (most recent call last): File "/home/stack/tempest-dir/tempest/test.py", line 107, in wrapper return f(self, *func_args, **func_kwargs) File "/home/stack/tempest-dir/tempest/scenario/test_network_v6.py", line 244, in test_dualnet_slaac_from_os self._prepare_and_test(address6_mode='slaac', dualnet=True) File "/home/stack/tempest-dir/tempest/scenario/test_network_v6.py", line 191, in _prepare_and_test CONF.validation.ping_timeout, 1)) File "/usr/lib/python2.7/site-packages/unittest2/case.py", line 678, in assertTrue raise self.failureException(msg) AssertionError: False is not true
I tested manually so far that executing something like: "command -v nmcli; if [ $? -eq 0 ]; then sudo nmcli device connect eth1; else sudo ip link set up eth1; fi" on vm during the test should works for all OSes like: Ubuntu, Cirros, Centos which don't have nmcli installed and for RHEL which has nmcli installed.
So after more checking of that, using nmcli will not solve problem on RHEL based image.
I compared behavior on RHEL 7.5 and RHEL 6.10 and it looks for me that it's regression in RHEL 7.5 so I reported bug: https://bugzilla.redhat.com/show_bug.cgi?id=1636350
Seems that fix for this may be responsible for failure which appeared in RHOS CI phase2. We see three testcases > tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_multi_prefix_dhcpv6_stateless[compute,id-cf1c4425-766b-45b8-be35-e2959728eb00,network] > tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic[compute,id-c5adff73-e961-41f1-b4a9-343614f18cfa,network] > tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_port_security_macspoofing_port[compute,id-7c0bb1a2-d053-49a4-98f9-ca1a1d849f63,network] are now failing as: > Traceback (most recent call last): > File "/home/stack/tempest-dir/tempest/test.py", line 107, in wrapper > return f(self, *func_args, **func_kwargs) > File "/home/stack/tempest-dir/tempest/scenario/test_network_v6.py", line 256, in test_dualnet_multi_prefix_dhcpv6_stateless > dualnet=True) > File "/home/stack/tempest-dir/tempest/scenario/test_network_v6.py", line 173, in _prepare_and_test > self.turn_nic6_on(sshv4_1, sid1) > File "/home/stack/tempest-dir/tempest/scenario/test_network_v6.py", line 158, in turn_nic6_on > ssh.set_nic_state(ssh.get_nic_name_by_mac(mac6)) > File "/home/stack/tempest-dir/tempest/common/utils/linux/remote_client.py", line 180, in set_nic_state > if self._sysconfig_network_scripts_dir_exists(ssh): > File "/home/stack/tempest-dir/tempest/common/utils/linux/remote_client.py", line 199, in _sysconfig_network_scripts_dir_exists > return "False" not in ssh.exec_command( > AttributeError: 'module' object has no attribute 'exec_command'
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0075