[network] openvswitch agent broken, uses ml2 conf on ubuntu

Bug #1314751 reported by Mark Vanderwiel
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack + Chef
Fix Released
High
Mark Vanderwiel

Bug Description

The ubuntu openvswtich agent package hard codes to use the ml2_conf.ini for it settings. Therefore the ml2_conf template would need parts of the [ovs] section from the openvswitch template.

There's a different bug for the redhat use case here: https://bugs.launchpad.net/openstack-chef/+bug/1311311

Tags: network
Revision history for this message
Darren Birkett (darren-birkett) wrote :

I'm not convinced this is actually a bug. In the cookbooks on ubuntu we template out the file

"/etc/default/neutron-server"

here: https://github.com/stackforge/cookbook-openstack-network/blob/master/templates/default/neutron-server.erb

When we are using ml2 as the core_plugin, this ends up containing:

NEUTRON_PLUGIN_CONFIG=/etc/neutron/plugins/ml2/ml2_conf.ini

And so this determines the config file that gets loaded along with the main neutron.conf:

/usr/bin/python /usr/bin/neutron-server --config-file /etc/neutron/neutron.conf --log-file /var/log/neutron/server.log --config-file /etc/neutron/plugins/ml2/ml2_conf.ini

If you change the value in /etc/default/neutron-server to point to the monolithic ovs plugin config file like this:

NEUTRON_PLUGIN_CONFIG=/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini

that is what gets loaded:

/usr/bin/python /usr/bin/neutron-server --config-file /etc/neutron/neutron.conf --log-file /var/log/neutron/server.log --config-file /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini

Simples!

The real problem here is that we need to port all of the ovs specific setting out of the monolithic ovs plugin config file, and in to the ml2 configuration file under an [ovs] section.

Revision history for this message
John Kasperski (jckasper) wrote :

I did some testing earlier this week in which I had an ml2_conf.ini file with just the ml2 properties, no [ovs] section. This was the only .ini file that was passed into neutron-server as --config-file. With that configuration, I was able to use OVS GRE and flat networks just fine. I do not believe that the [ovs] section is actually needed by the neutron-server.

The bug on ubuntu is with the logic for the neutron-openvswitch-agent. On the version of ubuntu that was looked at, the neutron_openvswitch_agent was hard coded to: /etc/neutron/plugins/ml2/ml2_conf.ini. The neutron-linuxbridge-agent on the other hand was hard coded to: /etc/neutron/plugins/linuxbridge/linuxbridge_conf.ini.

If the ubuntu neutron-openvswitch-agent was updated to always use /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini, I think everything would be fine.

Revision history for this message
Darren Birkett (darren-birkett) wrote :

John,

If you don't have any ovs section in the ml2 ini, neutron server (and ovs) is unable to read the ovs specific settings that it needs, specifically for GRE - because they are sitting in the ovs plugin inifile. Without a 'local_ip' option under the [ovs] section, ovs cannot properly set up GRE tunnel endpoints.

In my testing, I had to add in this section with this option before the GRE tunnel endpoints got created.

Personally, I think all settings should go under the relevant section in the ml2 inifile. The packaging should be fixed to load the ml2 inifile on the agent side, rather than sometimes being hardcoded to ml2, sometimes being hardcoded to [plugin-name] inifile. This is a packaging bug which can be worked around in the cookbooks until fixed.

This is neater as it keeps all config options in the main core_plugin file, ml2.

Revision history for this message
John Kasperski (jckasper) wrote :

Darren,

You are correct. The "local_ip" in the [ovs] section is necessary in order to setup the GRE tunnel. The tunnel is created by the neutron-openvswitch-agent. Only neutron-openvswitch-agent needs the [ovs] section, not the neutron-server process. When you look at the compute nodes, there is no neutron-server, there is only the neutron-openvswitch-agent so it makes sense that all of the [ovs] logic is handled by the agent instead of the neutron-server.

I'm guessing the reason why the GRE tunnel did you get created for you is because the neutron-openvswitch-agent (on Ubuntu) is hardcoded to look at ml2_conf.ini instead of the ovs_neutron_plugin.ini.

Ideally, I think all of the plugin .ini files should go away and everything should be added to neutron.conf. To accomplish this we would need to get the OpenStack neutron community to agree that this is the correct thing for neutron.

Revision history for this message
Darren Birkett (darren-birkett) wrote :

Well in theory we could just add everything to neutron.conf ourselves in the cookbooks - at the end of the day all the options get mashed together anyway by the conf loader. It would mean providing an empty plugin ini file for the initscripts on both ubuntu and centos, but I'm pretty sure that would just work.

Whether that's the right thing to do at this juncture or not, is a different question, but it's not a technical thing that would need changed in the neutron codebase.

Revision history for this message
John Kasperski (jckasper) wrote :

No, probably not the correct thing to do.

Revision history for this message
Mark Vanderwiel (vanderwl) wrote :

Darren, I created a new patch for the redhat side of this(bug 1311311) It's focus is on the agents and I think is a good way to go for now. For this bug on the ubuntu side, looks like we have to deal with the hardcoded nature of openvswitch using the ml2_conf.ini. Either we change that to point to the ovs_neutron_plugin.ini or we need to dup the entries into the ml2 file. What approach would you like to see for this?

Changed in openstack-chef:
milestone: none → juno-rc1
tags: added: network
Revision history for this message
JJ Asghar (d-jj) wrote :

Is this still an issue? Has there been any movement on this?

Revision history for this message
JJ Asghar (d-jj) wrote :

This is very much still an issue we talk about it here: http://youtu.be/GM0WEzc_G-A?t=7m18s

Revision history for this message
JJ Asghar (d-jj) wrote :

TODO: we need to find the bug that closes this issue. JJ may have written it.

Revision history for this message
Mark Vanderwiel (vanderwl) wrote :
Revision history for this message
Mark Vanderwiel (vanderwl) wrote :

I'm going to try a different approach here, a partial template. I think we can add a conditional
 <%= render "ovs_neutron_plugin.ini.erb" -%> to the ml2_conf_ini.erb and just pass some additional variables along in the ubuntu case. That should allow this to work as designed by the base neutron folks for ubuntu.

Changed in openstack-chef:
assignee: nobody → Mark Vanderwiel (vanderwl)
Changed in openstack-chef:
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to cookbook-openstack-network (master)

Fix proposed to branch: master
Review: https://review.openstack.org/161495

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

Reviewed: https://review.openstack.org/161495
Committed: https://git.openstack.org/cgit/stackforge/cookbook-openstack-network/commit/?id=7963c596c9a8bfbff6c1ea67d8851a5efea672f9
Submitter: Jenkins
Branch: master

commit 7963c596c9a8bfbff6c1ea67d8851a5efea672f9
Author: Mark Vanderwiel <email address hidden>
Date: Wed Mar 4 18:16:22 2015 -0600

    Fix ubuntu ml2_conf missing ovs section

    Used the existing ovs conf as a partial template to simply include
    in the ml2 conf. This keeps all the attributes the same.
    A more detailed spec will have to be done after some refactoring
    to allow for sections to be tested.

    Please give this idea a try, it seems to allow me to setup neutron
    on ubuntu with ml2. I'm working toward using this as a basis for
    getting the repo aio_neutron test working.

    Change-Id: Ia988f3d7ef1c280c40b55cea4f455710f673dd32
    Closes-Bug: #1314751

Changed in openstack-chef:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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