stack.sh isn't working after using VxLAN

Bug #1555001 reported by Shlomo
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
DragonFlow
Fix Released
Medium
Omer Anson

Bug Description

VxLan isn't removed at all while vport_geneve and openvswitch are being removed (sudo modprobe -r vport_geneve, sudo modprobe -r openvswitch).

Need to remove the VxLan as well.

Steps:
- Set VxLAN for tunneling
- run unstack.sh
- run stack.sh

result:
stack.sh failed - see attached log

Revision history for this message
Shlomo (shlominar) wrote :
Shlomo (shlominar)
description: updated
Yuli (stremovsky)
Changed in dragonflow:
importance: Undecided → Medium
Gal Sagie (gal-sagie)
Changed in dragonflow:
assignee: nobody → Omer Anson (omer-anson)
Revision history for this message
Shlomo (shlominar) wrote :

Need to add this command:
sudo modprobe -r vport_vxlan

Changed in dragonflow:
status: New → In Progress
Revision history for this message
Hong Hui Xiao (xiaohhui) wrote :

This bug may a bit out of date. In its reporting time, the df will use neutron's compile_ovs function to build ovs from git. In that function, the openvswitch will be unloaded from kernel and reload with new module. However, the vxlan is not considered, so, when you unstack, the vxlan is still in kernel. And again, stack.sh is running, when it tries to unload ovs, it will fail, the ovs is still occupied by vxlan! As a result, the ovs can't be installed. And error is observed.

However, df will not unload openvswitch from kernel now. So, the same scenario will not cause errors.

But it is still interesting in the vxlan(or gre) scenario, because they are not being considered. I would like to use this bug to add script for vxlan and gre.

In some case, if ovs is installed before devstack, and it is an old ovs, we still want the ovs be wiped out from OS and then install the new version.(for example, ovs 2.0.2 installed, however, 2.5.0 is desired).

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to dragonflow (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/369847

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to dragonflow (master)

Reviewed: https://review.openstack.org/369847
Committed: https://git.openstack.org/cgit/openstack/dragonflow/commit/?id=20425a9ba374649aa39ae3ce5b3fc1630cd0be1c
Submitter: Jenkins
Branch: master

commit 20425a9ba374649aa39ae3ce5b3fc1630cd0be1c
Author: Hong Hui Xiao <email address hidden>
Date: Wed Sep 14 11:25:13 2016 +0800

    Fix load_module_if_not_loaded not working

    "test lsmod | grep -q $MOD" will always return false, no matter if the
    module is loaded or not. This patch fixes that and also adds function
    to unload module from kernel.

    Change-Id: I7c51a085fd516115d00c35e0ea068bfa15db26f1
    Related-Bug: #1555001

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to dragonflow (master)

Reviewed: https://review.openstack.org/369865
Committed: https://git.openstack.org/cgit/openstack/dragonflow/commit/?id=2f85f7078082f63908cfc291f94ba6f0ab614937
Submitter: Jenkins
Branch: master

commit 2f85f7078082f63908cfc291f94ba6f0ab614937
Author: Hong Hui Xiao <email address hidden>
Date: Wed Sep 14 15:13:46 2016 +0800

    Remove vport_<tunnel_type> before removing openvswitch

    This patch will do following things:

    1) Not load geneve in devstack script. The kernel module for geneve
    (or vxlan or gre) will be loaded by openvswitch when the tunnel port
    is created. No need to explicitly load it.

    2) Removing vport_<tunnel_type> before removing openvswitch. Here,
    tunnel_type means geneve, vxlan and gre.

    Change-Id: I48ef91f13f26e61517f3b122e4d45d1906a2d335
    Closes-Bug: #1555001

Changed in dragonflow:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on dragonflow (master)

Change abandoned by Omer Anson (<email address hidden>) on branch: master
Review: https://review.openstack.org/298753
Reason: Thanks for the reminder. (And for actually writing the other patch, obviously (: ).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.