Open Stack

Hi Joe,

What do you suggest doing for someone using Puppet?

Should we create a symlink from ovs_neutron_plugin.ini to ml2_conf.ini 
for people with "old" packages?

What about linuxbridge mechanism? Should we:
- create a symlink from linuxbridge_conf.ini to ml2_conf.ini like OVS 
does and
- open a bug report to get package fixed so agent reads ml2_conf.ini?


This however raises the question: what if people are:
- Still using the old Linuxbridge plugin in Icehouse and update the 
package with the proposed fix? I suppose the agent will stop working 
from lack of configs in ml2_conf.ini.
- using OVS and upgrading from Havana to Icehouse while using the old 
OVS plugin. I suppose the agent will stop working from lack of configs 
in ml2_conf.ini.

IMO, nothing of this mess would have happened if people put the configs 
in the right file in the first place but here we are. =)

Mathieu

On 2014-07-23 12:30 PM, Joe Topjian wrote:
> Sorry for jumping into this conversation late.
>
> Indeed the default linuxbridge init scripts point to different files.
> I've taken two approaches with my Puppet scripts: either replace the
> init script with one that points to the ml2 file, or clobber the
> linuxbridge_conf.ini file with ml2 settings. I apologize for not doing
> the right thing and filing a bug. :/
>
> I've just finished setting up an OVS-based Neutron cloud, and although
> this wasn't a migration, I ran into similar issues that have been talked
> about in this thread:
>
> The "vlan 4095" point was very helpful! I was seeing the same thing and
> it was nice to learn the reason behind it.
>
> Additionally, like Robert, I was unable to get anything working until I
> added the "bridge_mappings" setting.
>
> And finally, when creating the "main" bridge that will "host" the trunk
> interface, that bridge cannot have the trunk port set to type internal.
> This seems logical, but it's easy for someone to make that mistake. For
> example, let's say the trunk interface is eth0. The documentation says
> to do this:
>
> ovs-vsctl add-br br-eth0
> ovs-vscl add-port br-eth0 eth0
>
> That sets everything up correctly. But let's say someone (ie me) says
> "whatever, I'll just call the bridge eth0":
>
> ovs-vsctl add-br eth0
>
> This will automatically add the eth0 interface to the eth0 bridge, but
> of type "internal". There are, of course, ovs commands to change that,
> but I haven't had a chance to look them up -- I just did the br-eth0
> route and all was good.
>
>
> On Mon, Jul 21, 2014 at 10:16 AM, Mathieu Gagné <mgagne at iweb.com
> <mailto:mgagne at iweb.com>> wrote:
>
>     On 2014-07-21 12:00 PM, Jonathan Proulx wrote:
>
>         Coming back to this after a break...
>
>         On my system (Ubuntu 12.04 Icehouse upgraded from havana) the agent
>         startup is clearly looking at the ml2_conf.ini and not the
>         openvswitch.ini:
>
>         # grep exec /etc/init/neutron-plugin-__openvswitch-agent.conf
>         exec start-stop-daemon --start --chuid neutron --exec
>         /usr/bin/neutron-openvswitch-__agent --
>         --config-file=/etc/neutron/__neutron.conf
>         --config-file=/etc/neutron/__plugins/ml2/ml2_conf.ini
>         --log-file=/var/log/neutron/__openvswitch-agent.log
>
>
>     omg... Linux Bridge agent upstart config file differs from the
>     Openvswitch's one.
>
>     Linuxbridge:
>     exec start-stop-daemon --start --chuid neutron --exec
>     /usr/bin/neutron-linuxbridge-__agent --
>     --config-file=/etc/neutron/__neutron.conf
>     --config-file=/etc/neutron/__plugins/linuxbridge/__linuxbridge_conf.ini
>     --log-file=/var/log/neutron/__linuxbridge-agent.log
>
>     Openvswitch:
>
>     exec start-stop-daemon --start --chuid neutron --exec
>     /usr/bin/neutron-openvswitch-__agent --
>     --config-file=/etc/neutron/__neutron.conf
>     --config-file=/etc/neutron/__plugins/ml2/ml2_conf.ini
>     --log-file=/var/log/neutron/__openvswitch-agent.log
>
>     I don't know what to say...
>
>     --
>     Mathieu
>
>
>     _________________________________________________
>     OpenStack-operators mailing list
>     OpenStack-operators at lists.__openstack.org
>     <mailto:OpenStack-operators at lists.openstack.org>
>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
>
>


-- 
Mathieu