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.
(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?
> 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
If you want to simply wipe the slate clean, you can add DELETE_BRIDGES=yes to /etc/sysconfig/openvswitch.
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.
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/
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?
Fixed package openstack-quantum-2012.2.1-6.el6ost is in brew.
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
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