[neutron] Is a provider of the "router" extension required also to provide the "extraroute" extension?
Thanks Bence for your response.
On Fri, Sep 27, 2019 at 9:45 AM Bence Romsics <bence.romsics at gmail.com>
> 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:
> 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,
Very much; many thanks!
-------------- next part --------------
An HTML attachment was scrubbed...