Bug 1731852

Summary: DHCPv6 related tests from tempest.scenario.test_network_v6.TestGettingAddress are failing on OSP-15 with RHEL8 guest image
Product: Red Hat OpenStack Reporter: Slawek Kaplonski <skaplons>
Component: openstack-tempestAssignee: Slawek Kaplonski <skaplons>
Status: CLOSED DUPLICATE QA Contact: Martin Kopec <mkopec>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15.0 (Stein)CC: apevec, lhh, slinaber, udesale
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-22 09:14:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Slawek Kaplonski 2019-07-22 08:28:47 UTC
Description of problem:
Tests from module tempest.scenario.test_network_v6.TestGettingAddress are failing on OSP-15 when RHEL8 is used as guest image.
At first glance it looks that RHEL 8 is using NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_STABLE_PRIVACY as addr-gen-mode and due to that "wrong" IPv6 address is configured on host.

Example of failure:

Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/tempest/common/utils/__init__.py", line 89, in wrapper
    return f(*func_args, **func_kwargs)
  File "/usr/lib/python3.6/site-packages/tempest/scenario/test_network_v6.py", line 273, in test_dualnet_dhcp6_stateless_from_os
    self._prepare_and_test(address6_mode='dhcpv6-stateless', dualnet=True)
  File "/usr/lib/python3.6/site-packages/tempest/scenario/test_network_v6.py", line 224, in _prepare_and_test
    (ip, srv['id'], ssh.exec_command("ip address")))
  File "/usr/lib/python3.6/site-packages/unittest2/case.py", line 693, in fail
    raise self.failureException(msg)
AssertionError: Address 2003::f816:3eff:fe54:9177 not configured for instance 786e183f-567a-4496-892a-702e5ed3a091, ip address output is
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:16:3e:d9:29:f4 brd ff:ff:ff:ff:ff:ff
    inet 10.100.0.13/28 brd 10.100.0.15 scope global dynamic noprefixroute eth0
       valid_lft 86074sec preferred_lft 86074sec
    inet6 fe80::f816:3eff:fed9:29f4/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:16:3e:54:91:77 brd ff:ff:ff:ff:ff:ff
    inet6 2003::d105:c69d:11c1:3f79/64 scope global dynamic noprefixroute 
       valid_lft 86323sec preferred_lft 14323sec
    inet6 fe80::adcf:ec57:fed1:56c8/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Comment 2 Martin Kopec 2019-07-22 09:14:21 UTC
I believe it's a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1714142

Slawek, please, have a look at the solution in BZ 1714142. Let me know if that solution fixes your issue. If it doesn't, please, feel free to reopen this bug.

*** This bug has been marked as a duplicate of bug 1714142 ***

Comment 3 Slawek Kaplonski 2019-07-22 09:29:59 UTC
@Martin: thx. Second part of BZ 1714142 is indeed duplicate of this issue. But I don't see any fix for it proposed anywhere. So I will try to push something u/s today or tomorrow.

Comment 4 Martin Kopec 2019-07-22 10:12:29 UTC
This should be the fix https://review.opendev.org/#/c/657018/
The review targets two issues based on the commit message.