[openstack-dev] [Neutron] Enabling/Disabling specific API extensions
brandon.logan at RACKSPACE.COM
Tue Jun 7 19:49:29 UTC 2016
On Tue, 2016-06-07 at 19:17 +0000, Sean M. Collins wrote:
> 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 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?
As far as I know, you can disable an extension by moving it out of that
api_extensions_path, renaming it with an _ in front of it, or the core
plugin or any loaded service plugins do not support it via the
support_extension_aliases variable. I don't know of any easier way to
do that. Hopefully I'm just not aware of one that exists.
> Further reading:
> : http://lists.openstack.org/pipermail/openstack-dev/2016-May/095095.html
> : https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L46
More information about the OpenStack-dev