yahoo-eng-team team mailing list archive

[Yang Yu <yangyu@xxxxxxxxxx>]

Public bug reported:

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.

** Affects: neutron
     Importance: Undecided
     Assignee: Yang Yu (yuyangbj)
         Status: New

** Changed in: neutron
     Assignee: (unassigned) => Yang Yu (yuyangbj)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1338977

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

Status in OpenStack Neutron (virtual network service):
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1338977/+subscriptions