[Rdo-list] Neutron-openswitch-agent configuration workaround in RDO Juno/Kilo and now in Liberty

[Matt Kassawara]

The installation guide has a small number of contributors, none of whom
belong to the packaging projects it supports. Furthermore, at least until
recently, none of the packaging projects respond in a timely fashion to
potential issues that we find... and we usually find them while updating
the installation guide at least a month prior to release which would also
help packagers fix issues prior to release. Given the popularity of the
installation guide, we would really appreciate each packaging project
contributing some resources that can help us address potential bugs and
avoid implementation of workarounds.

On Thu, Nov 5, 2015 at 8:27 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> Matt Kassawara <mkassawara at gmail.com> wrote:
>
> Several releases ago, neutron deprecated and removed the monolithic OVS
>> and Linux bridge plug-ins. During the deprecation cycle, the installation
>> guide changed the neutron instructions to use ML2 instead of the monolithic
>> OVS plug-in. However, the defunct configuration files
>> (plugins/openvswitch/ovs_neutron_plugin.ini and
>> plugins/linuxbridge/linuxbridge_conf.ini) lingered until the Liberty
>> release. The combination of migrating to ML2 and referencing configuration
>> files from the monolithic plug-ins (especially OVS with "plugin" in the
>> file name) caused significant confusion with our audience that already
>> struggles with neutron and installations in general. Some distributions and
>> deployment tools moved configuration for the OVS and Linux bridge agents
>> into the ml2_conf.ini file and changed the agent init scripts to read it.
>> At the time, implementing this approach in the installation guide seemed
>> like the best solution until neutron resolved the file name/location
>> problem in Liberty.
>>
>
> Agreed the naming in neutron was unfortunate. I believe it stayed the way
> it was for a while because it was not clear on first sight how to handle it
> in a backwards compatible way [in the end, we just renamed and left
> compatibility considerations to distributions.]
>
> Ihar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20151105/def01132/attachment.html>