Open Stack

Thanks Slawek.  Are you planning to leave this change in place?  I can
update my plugin's code, but that still leaves the likelihood of breakage if
- there's a new Rocky patch release
- a deployer is using an out-of-tree plugin with its own interface driver,
and upgrades to the Rocky patch release
- either they don't also upgrade their plugin code, or there isn't a plugin
update available because the plugin author hasn't noticed this problem yet.

Do you know if there will be another Rocky patch release, and if so when?

Best wishes,
    Neil


On Fri, May 15, 2020 at 4:17 PM Slawek Kaplonski <skaplons at redhat.com>
wrote:

> Hi,
>
> That is my fault as I proposed this backport actually.
> I know it was mistake and we should do it a bit different in stable
> branches to
> avoid breaking third party drivers really.
> Maybe we should also think about moving such base driver classes to
> neutron-lib
> to avoid such issues in the future.
>
> Once again sorry for that. I will be more careful in the future.
>
> On Fri, May 15, 2020 at 03:33:13PM +0100, Neil Jerram wrote:
> > I'm sorry, but this is a moan.
> >
> > This merge -
> >
> https://opendev.org/openstack/neutron/commit/a6fb2faaa5d46656db9085ad6bcfc65ded807871
> > -
> > to the Neutron stable/rocky branch on April 23rd, has broken my team's
> > Neutron plugin, by requiring 3rd party LinuxInterfaceDriver subclasses to
> > take a new 'link_up' argument in their 'plug_new' method.
> >
> > IMO, it should have been obvious to folk proposing or reviewing this,
> that
> > it would cause breakage.
> >
> > Does Neutron have a different understanding of "stable" than I do?  Or do
> > plugins other than OVN not matter anymore?
>
> --
> Slawek Kaplonski
> Senior software engineer
> Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200515/1983a23a/attachment-0001.html>