Open Stack

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.
> 
> https://review.openstack.org/#/c/318145/7
> 
> 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
> `api_extensions_path`[2]
> 
> https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L46
> 
> 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/095323.html
> http://lists.openstack.org/pipermail/openstack-dev/2016-May/095349.html
> http://lists.openstack.org/pipermail/openstack-dev/2016-May/095361.html
> 
> 
> [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
>