Open Stack

Hi Mathieu,

Good questions and I've been trying to think of some sort of answers that
are even slightly helpful. Unfortunately when I test these things in
lab/sandbox environments, I tend to do things that end up being more like
duct tape than an acceptable solution for wide adoption.

I think Puppet should attempt to do what would be the result of any fixed
packaging bugs. If linuxbridge follows suit with OVS, then create a
symlink. And also make sure the init script is correct. As Jon says, it
really doesn't matter what the ini files are called as long as they are
specified in the init script, but consistency is always a good thing.

Regarding the contents of the ini files, it seems that there are pre-ML2
options that should be specified in various config files in order to get
things working. I think just making sure that all correct settings are
specified in an ini file (regardless of what ini file, as long as it's in
the init script) should be good.

However, I think we're all in a situation where we don't even know what the
right set of settings should be...

I apologize, but that probably doesn't help at all. :/

On Wed, Jul 23, 2014 at 10:43 AM, Mathieu Gagné <mgagne at iweb.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140724/75d88391/attachment-0001.html>