[openstack-dev] [Neutron] Enabling/Disabling specific API extensions

Sean M. Collins sean at coreitpro.com
Tue Jun 7 19:17:41 UTC 2016

The patch that switches DevStack over to using the Neutron API to
discover what features are available has landed.


The quick summary is that things like Q_L3_ENABLED[1] and if certain
services are running/enabled has been replaced with checks for if an API
extension is available. The point being, the Networking API should be
discoverable and features should be determined based on what extensions
are available, instead of some DevStack-y bits.

Neutron controls what API extensions are loaded via the


So by default Neutron loads up every extension that is included in tree.

But what if a deployment doesn't want to support an API extension?

With third party CI, prior to https://review.openstack.org/#/c/318145 -
systems could get away with it by not enabling services - like q-l3 - and
that would stop subnets and routers being created. After that patch,
well that's not the case.

So is there a way to configure what API extensions are available, so that
if a CI system doesn't want to provide the ability to create Neutron
routers, they can disable the router API extension in some manner more
graceful than rm'ing the extension file?

I know at least in one deployment I was involved with, we didn't deploy
the L3 agent, but I don't believe we disabled or deleted the router API
extension, so users would try and create routers and other resources
then wonder why nothing would ever work.

>From a discoverability standpoint - do we provide fine-grained a way for 
deployers to enable/disable specific API extensions? 

Further reading:


[1]: http://lists.openstack.org/pipermail/openstack-dev/2016-May/095095.html
[2]: https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L46

Sean M. Collins

More information about the OpenStack-dev mailing list