Open Stack

Reviewed:  https://review.openstack.org/96919
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d00446be1739c93921e3b88763e05fc194ea9b2b
Submitter: Jenkins
Branch:    stable/icehouse

commit d00446be1739c93921e3b88763e05fc194ea9b2b
Author: Kyle Mestery <kmestery at cisco.com>
Date:   Fri May 16 04:21:32 2014 +0000

    Reprogram flows when ovs-vswitchd restarts
    
    When OVS is restarted, by default it will not reprogram flows which were
    programmed. For the case of the OVS agent, this means a restart will cause
    all traffic to be switched using the NORMAL action. This is undesirable for
    a number of reasons, including obvious security reasons.
    
    This change provides a way for the agent to check if a restart of ovs-vswitchd
    has happened in the main agent loop. If a restart of ovs-vswitchd is detected,
    the agent will run through the setup of the bridges on the host and reprogram
    flows for all the ports connected.
    
    DocImpact
    This changes adds a new table (table 23) to the integration bridge, with a
    single 'drop' flow. This is used to monitor OVS restarts and to reprogram
    flows from the agent.
    
    Conflicts:
    	neutron/plugins/openvswitch/common/constants.py
    
    Change-Id: If9e07465c43115838de23e12a4e0087c9218cea2
    Closes-Bug: #1290486
    (cherry picked from commit 8e9f00a19dab98e5cfc7ca32beb9f17ebb5bc1bb)


** Changed in: neutron/icehouse
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1290486

Title:
  neutron-openvswitch-agent does not recreate flows after ovsdb-server
  restarts

Status in OpenStack Neutron (virtual network service):
  Confirmed
Status in neutron icehouse series:
  Fix Committed
Status in tripleo - openstack on openstack:
  Triaged

Bug description:
  The DHCP requests were not being responded to after they were seen on
  the undercloud network interface.  The neutron services were restarted
  in an attempt to ensure they had the newest configuration and knew
  they were supposed to respond to the requests.

  Rather than using the heat stack create (called in
  devtest_overcloud.sh) to test, it was simple to use the following to
  directly boot a baremetal node.

      nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \
            --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \
            bm-test1

  Whilst the baremetal node was attempting to pxe boot a restart of the
  neutron services was performed.  This allowed the baremetal node to
  boot.

  It has been observed that a neutron restart was needed for each
  subsequent reboot of the baremetal nodes to succeed.

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