tempest

Tempest IPv6 scenario tests use IPv4 and floating IPs to connect and test

Bug #1401726 reported by Sean M. Collins
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tempest
Confirmed
High
Unassigned

Bug Description

The ipv6 network tests are extremely useful, since they will help uncover regressions in Neutron routers that have IPv6 subnets attached. They have already uncovered bugs in Neutron's DVR feature (https://bugs.launchpad.net/neutron/+bug/1401656).

Future work should be done to have the tempest tests connect to the IPv6 address of the guest VMs, and also do pings that cross router boundaries to ensure end to end connectivity, since the current tests just ensure that two VMs attached to a Neutron router have IPv6 connectivity and can ping each other on the same L2 domain.

Matthew Treinish (treinish)
Changed in tempest:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Sean M. Collins (scollins)
Revision history for this message
Ken'ichi Ohmichi (oomichi) wrote :

We need still this report at this time because of the following IRC conversation.

 12:43 (oomichi) sc68cal: hi, does current test_network_v6.py cover https://bugs.launchpad.net/tempest/+bug/1401726 ?
 12:43 (oomichi) sc68cal: https://github.com/openstack/tempest/blob/master/tempest/scenario/test_network_v6.py
 12:43 (oomichi) sc68cal: or still do we need to open that?
 12:46 (sc68cal) oomichi: yes that is still the case, we ssh into an instance via IPv4 and then do v6 connectivity checks to a second vm
 12:48 (oomichi) sc68cal: ah, the bug report requires ssh into an instance via IPv6, instead of v4

Revision history for this message
Andrea Frittoli (andrea-frittoli) wrote :

Using floating IP (only available for IPv4) makes the test more portable, since tenant networks are not always reachable from the test driver. We could use the project_network_reachable flag [0] to do an extra connectivity check to the IPv6 IP when possible, but I would not remove the ssh over IPv4 floating IP in any case.

I wonder if running this tests in one of the multi node jobs - forcing the two VMs to be hosted on different hypervisors - would already improve the effectiveness of the tests in terms of going beyond the L2 domain.

Sean this is assigned to you, are you looking into this? If not we shall remove the assignee so someone can pickup the work.

[0] http://git.openstack.org/cgit/openstack/tempest/tree/tempest/config.py#n550

Revision history for this message
chandan kumar (chkumar246) wrote :

Unassigning this bug as there is no activity from last 6 months. If you are still want to work on this bug, feel free to assign yourself.

Changed in tempest:
assignee: Sean M. Collins (scollins) → nobody
Revision history for this message
Doug Schveninger (ds6901) wrote :

tempest and neutron-tempest-plugin have ipv6. Can we close this bug and let other open more specific bug since this is so old
https://github.com/openstack/neutron-tempest-plugin/search?q=ipv6&unscoped_q=ipv6

Revision history for this message
Dr. Jens Harbott (j-harbott) wrote :

IMO this bug has two very specific tasks not implemented yet:

- Test L3 connectivity via IPv6 between two instances
- Connect to instances via IPv6 instead via a (v4) floating IP

One might split this into two bugs but as long a noone is going to start real work on implementing one of these, the current state seems fine to me. (Not saying that it's fine that nobody has cared about this in almost 5 years.)

Paras Babbar (pbabbar)
Changed in tempest:
assignee: nobody → Paras Babbar (pbabbar)
Revision history for this message
Paras Babbar (pbabbar) wrote :

I might not be able to work on this for this wallaby cycle, if someone can take this and have bandwidth. feel free to take it.

Changed in tempest:
assignee: Paras Babbar (pbabbar) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.