Using OpenvSwitch, all devices with name "tapxxx" attached to OVS bridge can not be synchronized successfully when ovs_use_veth is set to True

Bug #1338977 reported by Yang Yu
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Expired
Undecided
Unassigned

Bug Description

OpenStack will create a device attached to the OVS integration bridge as a dhcp server, so whenever you create a network in OpenStack, there will be a tap device created and attached to the OVS integration bridge such as below.

stack@vm:/opt/stack/tempest$ sudo ovs-vsctl show
67b6d3bf-ff99-45da-9fea-a9d17385bc9d
    Bridge br-int
        Port "tap865468b3-57"
            tag: 7
            Interface "tap865468b3-57"
                type: internal
        Port "eth1"
            Interface "eth1"
        Port "tapbd8e5831-c9"
            Interface "tapbd8e5831-c9"
                type: internal
    ovs_version: "1.4.6"

stack@vm:/opt/stack/tempest$ sudo ip netns exec qdhcp-dd25353d-dfc1-4bf1-a67b-a24fe6a29058 ip a
20: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
24: ns-any: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 56:b7:ff:07:dc:85 brd ff:ff:ff:ff:ff:ff
50: tap865468b3-57: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:50:56:9b:95:48 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.2/24 brd 10.0.0.255 scope global tap865468b3-57
    inet 169.254.169.254/16 brd 169.254.255.255 scope global tap865468b3-57
    inet6 fe80::250:56ff:fe9b:9548/64 scope link
       valid_lft forever preferred_lft forever

And when you remove the integration bridge carelessly, you can create the bridge with same name manually, and restart the dhcp agent to get all tap devices back.

But the devices can not be set correctly when ovs_use_veth is set to True. If ovs_use_veth is set to True, there will be two peer devices created, one is named ns-xxxxx, another one is named tapxxxxx. We need to make sure tapxxxxx could be attached to the ovs integration bridge automatically using the scenario above.

Tags: ovs
Yang Yu (yuyangbj)
Changed in neutron:
assignee: nobody → Yang Yu (yuyangbj)
tags: added: ovs
Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

I'm not sure 'And when you remove the integration bridge carelessly' is a valid cloud scenario

Changed in neutron:
status: New → Incomplete
Revision history for this message
Cedric Brandily (cbrandily) wrote :

This bug is > 365 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

Changed in neutron:
assignee: Yang Yu (yuyangbj) → nobody
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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