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 > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev