RDO tickets are now tracked in Jira https://issues.redhat.com/projects/RDO/issues/
Bug 1081011 - L2 agent fails to start with VXLAN configuration
Summary: L2 agent fails to start with VXLAN configuration
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: RDO
Classification: Community
Component: openstack-neutron
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Terry Wilson
QA Contact: Ofer Blaut
URL:
Whiteboard:
Depends On:
Blocks: 1100164 1111697
TreeView+ depends on / blocked
 
Reported: 2014-03-26 13:33 UTC by Ofer Blaut
Modified: 2016-04-26 23:16 UTC (History)
11 users (show)

Fixed In Version: openstack-neutron-2014.1-19.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1100164 (view as bug list)
Environment:
Last Closed: 2015-03-25 22:18:36 UTC
Embargoed:


Attachments (Terms of Use)
OVS agent logs (3.14 KB, text/plain)
2014-03-26 13:33 UTC, Ofer Blaut
no flags Details
neutron files on host (24.46 KB, application/x-gzip)
2014-05-22 07:05 UTC, Ofer Blaut
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1322139 0 None None None Never
OpenStack gerrit 88121 0 None None None Never

Description Ofer Blaut 2014-03-26 13:33:56 UTC
Created attachment 879004 [details]
OVS agent logs

Description of problem:

I have used foreman to install openstack RDO with VXLAN configuration

L2 agent fails to start ( attached logs and info )

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


How reproducible:


Steps to Reproduce:
1. install openstack with foreman 
2. check l2 agent status on both neutron networker and compute node
3.

Actual results:

neutron-openvswitch-agent:              dead

Expected results:

neutron-openvswitch-agent:              active

Additional info:

Comment 1 Ofer Blaut 2014-03-26 13:34:56 UTC
Was tested with RHEL 6.5

Comment 2 lpeer 2014-03-31 11:57:54 UTC
can you please attach config files of your setup

Comment 3 Jakub Libosvar 2014-04-01 14:08:53 UTC
Also running with debug=True would be helpful. There is meaningful message prior to checking to see, what the versions are.

Comment 4 Terry Wilson 2014-04-08 15:14:26 UTC
This might also be related to the ovs_neutron_plugin.ini/plugin.ini permissions issues.

Comment 5 Terry Wilson 2014-04-14 16:43:23 UTC
It looks like the version check for the openvswitch kernel module doesn't work for us because modinfo doesn't have a "version:" field for openvswitch (or for most of the modules I have loaded on my RHEL box). So this code is broken:

470 def get_installed_ovs_klm_version():
471     args = ["modinfo", "openvswitch"]
472     try:
473         cmd = utils.execute(args)
474         for line in cmd.split('\n'):
475             if 'version: ' in line and not 'srcversion' in line:
476                 ver = re.findall("\d+\.\d+", line)
477                 return ver[0]
478     except Exception:
479         LOG.exception(_("Unable to retrieve OVS kernel module version."))

Seeing as this is the only information we have:

[root@localhost ~]# modinfo openvswitch
filename:       /lib/modules/2.6.32-431.11.2.el6.x86_64/kernel/net/openvswitch/openvswitch.ko
license:        GPL
description:    Open vSwitch switching datapath
srcversion:     993363C44DF474BD67B03CC
depends:        vxlan
vermagic:       2.6.32-431.11.2.el6.x86_64 SMP mod_unload modversions

I see no way to fix this in the upstream code at all. We could disable the check downstream or ship the kernel module with an actual "version" field. For reference, on Ubuntu:

terry@ubuntu1310:~$ modinfo openvswitch
filename:       /lib/modules/3.11.0-12-generic/updates/dkms/openvswitch.ko
version:        1.10.2
license:        GPL
description:    Open vSwitch switching datapath
srcversion:     3367192C878D3C0CD7F68D2
depends:        
vermagic:       3.11.0-12-generic SMP mod_unload modversions 


This is again a very real example of why we need upstream gating jobs that run on RHEL.

Comment 6 Terry Wilson 2014-04-17 15:07:50 UTC
Fix submitted upstream for review: https://review.openstack.org/#/c/88121/

Comment 7 Ofer Blaut 2014-05-22 07:05:45 UTC
Created attachment 898240 [details]
neutron files on host

Added files as requested

Comment 8 Ofer Blaut 2014-05-22 10:40:35 UTC
1. edit /usr/lib/python2.7/site-packages/neutron/plugins/openvswitch/common/constants.py

2. change :

# The first version of the Linux kernel with converged VXLAN code for OVS
MINIMUM_LINUX_KERNEL_OVS_VXLAN = "3.10.0"

3.  service neutron-openvswitch-agent restart

Comment 10 Terry Wilson 2014-05-27 16:20:54 UTC
wes: I haven't tried that patch yet, but I don't see how it would work. The minimum kernel version specified in the source is 3.13.0, and RHEL7 has 3.10.0 I thought? So it should still fail the check w/o a downstream patch. The code still is looking for version: line which RHEL doesn't show as well.

The real fix is to just remove this check altogether from upstream. It is silly. Downstream, easy enough to work around with a patch.

Comment 11 Miguel Angel Ajo 2014-05-28 15:01:11 UTC
Setting back to Terry Wilson, as we commited a temporary workaround for RDO, but he's working on the final upstream solution that works for all..

Comment 12 Ihar Hrachyshka 2014-06-18 11:06:59 UTC
I think this is fixed since openstack-neutron-2014.1-19.el7.noarch.rpm. If there is additional u/s work to handle that, this should belong there and not in RH bugzilla. So moving to ON_QA.

Comment 13 Ofer Blaut 2014-06-18 11:59:19 UTC
Was tested downstream https://bugzilla.redhat.com/show_bug.cgi?id=1100164

Comment 14 wes hayutin 2014-06-18 12:03:33 UTC
This bug is still open on RDO.
The updated rpm has not yet made it into the stage or production RDO repositories.

Comment 15 Kevin Fox 2014-06-20 15:29:33 UTC
EL6 has the same problem. I've been patching out the kernel version check and things are working for me.

Comment 16 Lars Kellogg-Stedman 2015-03-20 20:55:16 UTC
Terry: are there any plans to backport this fix into the EL6/icehouse packages, or is that a dead end?

Comment 17 Kevin Fox 2015-03-20 21:35:24 UTC
RDO has dropped support for EL6 in Juno. Sounds like a dead end.

Comment 18 Terry Wilson 2015-03-25 22:18:36 UTC
This fix should already be backported to RHOS5, EL6/7 and newer versions of RDO are fine. So I'm going to go ahead and close this one.


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