Open Stack

Thanks Bence for your response.

On Fri, Sep 27, 2019 at 9:45 AM Bence Romsics <bence.romsics at gmail.com>
wrote:

> Hi Neil,
>
> Neutron extensions are to be treated as optional (one by one) from an
> API user point of view. Many reference implementations implement
> multiple extensions at once in the same plugin and by that may create
> the (false) expectation the extensions always come together. But as
> soon as another cloud loads different plugins this expectation is
> going to break.
>

Thank you; yes, that is what I would have guessed too, unless there was a
declaration somewhere that some specific extensions are now mandatory.


> For example this is the l3 service plugin's extension list:
>
>
> https://github.com/openstack/neutron/blob/8a584171cd505593c69f9149aa58c6aa9b9e7ac3/neutron/services/l3_router/l3_router_plugin.py#L95
>
> But another plugin loaded in another cloud may choose to implement a
> different set of extensions. So I'd argue the client should be more
> lenient here and accept when the 'routes' attribute is not there.
>

I will propose a patch for that.


>
> It's another interesting question what may changed in the Calico CI,
> I'd probably start with this line in the log you linked:
>
> 2019-09-26 18:32:52.772 | ++
> /opt/stack/new/networking-calico/devstack/plugin.sh:source:98 :
> inidelete /etc/neutron/neutron.conf DEFAULT service_plugins
>
> That tells Neutron not to load any service plugins - including the l3
> service plugin.
>

That has been the case with Calico for a long time.  Instead of loading the
l3 service plugin, the Calico core plugin provides the router and
floatingip resources by inheriting from l3_db.L3_NAT_db_mixin, and
customizes some of the floating IP methods, as Calico implements those
differently from the reference implementation.

At https://review.opendev.org/#/c/685139/ I've tried a few iterations to
get this approach to generate the 'routes' attribute as well, but none of
those has worked yet.


> Hope that helps,
> Bence
>

Very much; many thanks!
     Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190927/89ee2ab0/attachment.html>