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

Kevin Benton kevin at benton.pub
Wed Jun 8 03:32:07 UTC 2016


I think we want to be careful about allowing every extension to be
configurable by the operator because plugins might expect certain
extensions to be loaded since they are defined in code. I suppose we could
have a way that it is just disabled at the API level but all of the code is
still loaded, but I would want to make sure we have a good use case before
we add more knobs to change API behavior.

For the L3 example, you can just disable the L3 service plugin and the l3
extensions will be gone since they are loaded by that plugin.

On Tue, Jun 7, 2016 at 12:49 PM, Brandon Logan <brandon.logan at rackspace.com>
wrote:

> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160607/d53a530d/attachment.html>


More information about the OpenStack-dev mailing list