[neutron] Is a provider of the "router" extension required also to provide the "extraroute" extension?
Hi Neutrinos - Calico's plugin has recently started failing CI, at the point where devstack initial network creation does "openstack router create ...", with the classic error "'NoneType' object is not iterable" [1], and I think this is because openstackclient assumes [2] that the returned router dict will always have a 'routes' field. If my analysis is correct, is that a correct assumption, or should openstackclient be more forgiving here? [1] https://openstack.fortnebula.com:13808/v1/AUTH_e8fd161dc34c421a979a9e6421f82... [2] https://opendev.org/openstack/python-openstackclient/src/branch/master/opens... Many thanks, Neil
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. For example this is the l3 service plugin's extension list: https://github.com/openstack/neutron/blob/8a584171cd505593c69f9149aa58c6aa9b... 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. 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. Hope that helps, Bence
Thanks Bence for your response. On Fri, Sep 27, 2019 at 9:45 AM Bence Romsics <bence.romsics@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/8a584171cd505593c69f9149aa58c6aa9b...
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
participants (2)
-
Bence Romsics
-
Neil Jerram