<div dir="ltr"><div><div>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.</div></div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 7, 2016 at 12:49 PM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, 2016-06-07 at 19:17 +0000, Sean M. Collins wrote:<br>
> The patch that switches DevStack over to using the Neutron API to<br>
> discover what features are available has landed.<br>
><br>
> <a href="https://review.openstack.org/#/c/318145/7" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/318145/7</a><br>
><br>
> The quick summary is that things like Q_L3_ENABLED[1] and if certain<br>
> services are running/enabled has been replaced with checks for if an API<br>
> extension is available. The point being, the Networking API should be<br>
> discoverable and features should be determined based on what extensions<br>
> are available, instead of some DevStack-y bits.<br>
><br>
> Neutron controls what API extensions are loaded via the<br>
> `api_extensions_path`[2]<br>
><br>
> <a href="https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L46" rel="noreferrer" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L46</a><br>
><br>
> So by default Neutron loads up every extension that is included in tree.<br>
><br>
> But what if a deployment doesn't want to support an API extension?<br>
><br>
> With third party CI, prior to <a href="https://review.openstack.org/#/c/318145" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/318145</a> -<br>
> systems could get away with it by not enabling services - like q-l3 - and<br>
> that would stop subnets and routers being created. After that patch,<br>
> well that's not the case.<br>
><br>
> So is there a way to configure what API extensions are available, so that<br>
> if a CI system doesn't want to provide the ability to create Neutron<br>
> routers, they can disable the router API extension in some manner more<br>
> graceful than rm'ing the extension file?<br>
><br>
> I know at least in one deployment I was involved with, we didn't deploy<br>
> the L3 agent, but I don't believe we disabled or deleted the router API<br>
> extension, so users would try and create routers and other resources<br>
> then wonder why nothing would ever work.<br>
><br>
> From a discoverability standpoint - do we provide fine-grained a way for<br>
> deployers to enable/disable specific API extensions?<br>
<br>
</div></div>As far as I know, you can disable an extension by moving it out of that<br>
api_extensions_path, renaming it with an _ in front of it, or the core<br>
plugin or any loaded service plugins do not support it via the<br>
support_extension_aliases variable.  I don't know of any easier way to<br>
do that.  Hopefully I'm just not aware of one that exists.<br>
<span class="im HOEnZb"><br>
><br>
><br>
> Further reading:<br>
><br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-May/095323.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-May/095323.html</a><br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-May/095349.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-May/095349.html</a><br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-May/095361.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-May/095361.html</a><br>
><br>
><br>
> [1]: <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-May/095095.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-May/095095.html</a><br>
> [2]: <a href="https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L46" rel="noreferrer" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L46</a><br>
><br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>