Uploaded image for project: 'ovsdb'
  1. ovsdb
  2. OVSDB-139

OVSDB needs to be more proactive in reporting errors with underlying OVS instances

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Done
    • None
    • unspecified
    • openstack.net-virt
    • None
    • Operating System: Linux
      Platform: All

      When using OpenStack with ODL integration, Neutron will send REST API calls to ODL for different network creation/configuration requests. As of right now OVSDB will always return 200 OK when asked to provision underlying VXLAN tunnels, flows, etc to the OVS instances below it. There should be some checking during the Neutron call to ensure to the best of ODL's ability that the network will be able to be provisioned.

      In the case of a tenant instance coming up, ODL relies on two pieces of information: Neutron call and nova adding the tap port to the OVS instance on the compute side. As of right now there is discussion on how ODL can handle error reporting for this case where there is a synchronous expectaion from Neutron and an asynchronous underlying operation.

      However, in the case of bridges (br-int to be more specific), if OVSDB receives a request to provision bridges that either do not exist or have gone down, OVSDB should be proactive enough to tell Neutron that there is an error and it cannot configure the bridge correctly.

      Right now the behavior is as follows:
      1. Working setup with topology as one compute node, and one controller/network node where there is an OVS instance on each node.
      2. Remove br-int on control/network node.
      3. In Neutron add entwork, subnet, router. All gives 200 OK.
      4. Now bring up a tenant instance. ODL will send back 200 OK and provision one end of the VXLAN tunnel and send flows to the br-int on compute.
      5. Other side of the tunnel is completly missing since br-int is not there. This should be caught by ODL and reported to Neutron as an error.

      Caveat here is removing br-int on compute will cause nova to actually report an error since the tenant cannot attach the tap port to the br-int so that case is covered, but ODL should still also report an error there.

      Please see attached Neutron and karaf logs.

            Unassigned Unassigned
            trozet Tim Rozet
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: