[Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts
Roman Podoliaka
rpodolyaka at mirantis.com
Thu Jun 19 09:48:14 UTC 2014
Sorry for a long reply, wasn't subscribed for the notifications and
missed you comments :(
So I've double-checked I'm running the neutron master. This doesn't seem
to be an L3-agent issue. I'm running Neutron master as of commit
24718e6f1764e95f0c393ba042546e3584981b31 (Ubuntu 14.04,
3.13.0-29-generic, OVS 2.0.1+git20140120-0ubuntu2).
Steps to reproduce:
1. Run tripleo devtest story. This will give you a 3 node cluster - 1 controller node + 2 compute nodes. Neutron ML2 plugin is used, OVS agents are run on each node.
2. SSH to a controller node.
3. Start pinging the VM using its private IP address from a DHCP agent namespace.
4. SSH to a compute node running the VM.
5. Restart the OVS.
6. The ping stops working until neutron-openvswitch-agent is restarted on the compute node.
Right after OVS restart I see this in neutron-openvswitch-agent log: http://paste.openstack.org/show/84472/
The complete log is here http://paste.openstack.org/show/84473/ (there are some errors, but I'm not sure they are related to this problem, 'WAS HERE' is a string I log to ensure the code of your fix is executed)
--
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):
Fix Released
Status in neutron icehouse series:
Fix Released
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
More information about the Openstack-security
mailing list