[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 redhat com> wrote:
Matt Kassawara <mkassawara 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.]


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]