Bug 889786 - OVS maintains tap devices after reboot
OVS maintains tap devices after reboot
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-quantum (Show other bugs)
2.0 (Folsom)
Unspecified Unspecified
high Severity high
: snapshot3
: 2.1
Assigned To: Gary Kotton
Ofer Blaut
: Triaged
Depends On:
Blocks: quantum_ovs_tracker
  Show dependency treegraph
 
Reported: 2012-12-23 09:35 EST by Gary Kotton
Modified: 2016-04-26 12:21 EDT (History)
6 users (show)

See Also:
Fixed In Version: openstack-quantum-2012.2.3-2.el6ost
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-05 13:30:30 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1091605 None None None Never

  None (edit)
Description Gary Kotton 2012-12-23 09:35:48 EST
Description of problem:
If X tap device were created at runtime, say for example by the DHCP agent, and added to the OVS bridge, then, when the appliance is rebooted the OVS maintains the tap devices.

This causes havovs with the quantum agents (upstream bug https://code.launchpad.net/bugs/1091605)


It would be ideal if there was a way on configuring the OVS so that this will not be persistant after a reboot.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. create network
2. create subnet
3. reboot
  
Actual results:
See that the tap device is part of the ovs after reboot

Expected results:


Additional info:
Upstream fix - https://review.openstack.org/#/c/18302/

When we integrate the stable/folsom code we will need to invoke this as part of the boot process when using ovs plugin.
Comment 2 Alan Pevec 2013-01-09 13:02:04 EST
(In reply to comment #0)
> It would be ideal if there was a way on configuring the OVS so that this
> will not be persistant after a reboot.

Should that part be filed as RFE against openvswitch?
 
> When we integrate the stable/folsom code we will need to invoke this as part
> of the boot process when using ovs plugin.

So you're saying we need to include running quantum-ovs-cleanup in quantum-openvswitch-agent initscript?
Comment 4 Alan Pevec 2013-01-22 13:37:49 EST
> When we integrate the stable/folsom code we will need to invoke this as part
> of the boot process when using ovs plugin.

This is now in stable/folsom: https://review.openstack.org/#/c/18638/
Once that's included in RPM, I propose following changes in packaging:
- change startup priority of quantum-openvswitch-agent to 97
  this ensures it runs before other quantum*agent initscripts
  which have # chkconfig:   - 98 02
- add quantum-ovs-cleanup in quantum-openvswitch-agent.init (patch below)

Open questions:
- "service quantum-openvswitch-agent restart" would perform ovs cleanup, is that ok or not?
- why upstream has not chosen to perform cleanup in bin/quantum-openvswitch-agent instead of separate shell script?

--- a/quantum-openvswitch-agent.init
+++ b/quantum-openvswitch-agent.init
@@ -2,7 +2,7 @@
 #
 # quantum-openvswitch-agent  OpenStack Open vSwitch plugin
 #
-# chkconfig:   - 98 02
+# chkconfig:   - 97 02
 # description: Support virtual networks using Open vSwitch
 ### END INIT INFO
 
@@ -23,6 +23,8 @@ start() {
     [ -x $exec ] || exit 5
     [ -f $config ] || exit 6
     echo -n $"Starting $prog: "
+    echo -n $" ovs-cleanup "
+    /usr/bin/quantum-ovs-cleanup --config-file /etc/$proj/$proj.conf --config-file $config
     daemon --user quantum --pidfile $pidfile "$exec --log-file /var/log/$proj/$plugin.log --config-file /etc/$proj/$proj.conf --config-file $config &>/dev/null & echo \$! > $pidfile"
     retval=$?
     echo
Comment 5 Chris Wright 2013-01-22 17:55:44 EST
If you want to simply wipe the slate clean, you can add DELETE_BRIDGES=yes to /etc/sysconfig/openvswitch.
Comment 6 Gary Kotton 2013-01-23 00:17:56 EST
I think that DELETE_BRIDGES may be too extreme and may cause some complexity in rebuilding interfaces that are not relevant to Quantum.

Upstream we decided to leave this as a separate script that usrs can invoke when they want. Incorporating this into the OVS agent script may be challengin (as Alan has mentioedn above). A restart of the agent should not purge the OVS of the tap devices.
Comment 7 Gary Kotton 2013-01-23 11:18:06 EST
The following solution is an option:

1. Create a init script that would invoke the ovs_cleanup_utility. This is run on init and has # chkconfig:   - 96 02
2. The script should always be invoked. If and only if open vswitch is installed will it do the actual cleanup

The packages will require https://review.openstack.org/#/c/18638/
Comment 8 Bob Kukura 2013-01-23 12:50:32 EST
Gary's option above makes sense to me. 

I think the new init script, and the ovs_cleanup_utility itself, should both be packaged with the openvswitch plugin, and only enabled if that plugin is configured. But I see that the code is in quantum.agent rather than in quantum.plugins.openvswitch upstream. Is there a reason for this? Would it ever be useful somewhere were the openvswitch agent is not run? Doesn't it need to access the openvswitch config files, which are packaged with the openvswitch plugin?
Comment 11 Bob Kukura 2013-01-29 23:59:01 EST
Fixed package openstack-quantum-2012.2.1-6.el6ost is in brew.
Comment 22 Ofer Blaut 2013-02-18 02:29:55 EST
 I have 
1. created network and subnets and VMs
2. disabled dhcp -  chkconfig quantum-dhcp-agent off
3. reboot the host and checked no TAPs are created on host (ifconfig) and OVS

openstack-quantum-2012.2.3-3.el6ost.noarch
Comment 24 errata-xmlrpc 2013-03-05 13:30:30 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0593.html

Note You need to log in before you can comment on or make changes to this bug.