Bug 1731852 - DHCPv6 related tests from tempest.scenario.test_network_v6.TestGettingAddress are failing on OSP-15 with RHEL8 guest image
Summary: DHCPv6 related tests from tempest.scenario.test_network_v6.TestGettingAddress...
Keywords:
Status: CLOSED DUPLICATE of bug 1714142
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tempest
Version: 15.0 (Stein)
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Slawek Kaplonski
QA Contact: Martin Kopec
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-22 08:28 UTC by Slawek Kaplonski
Modified: 2019-07-22 10:12 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-22 09:14:21 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.