<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 9, 2015 at 9:35 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</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 03/07/2015 07:31 PM, Jay Pipes wrote:<br>
> Hi Stackers,<br>
><br>
> Now that microversions have been introduced to the Nova API (meaning we<br>
> can now have novaclient request, say, version 2.3 of the Nova API using<br>
> the special X-OpenStack-Nova-API-Version HTTP header), is there any good<br>
> reason to require API extensions at all for *new* functionality.<br>
><br>
> Sergey Nikitin is currently in the process of code review for the final<br>
> patch that adds server instance tagging to the Nova API:<br>
><br>
> <a href="https://review.openstack.org/#/c/128940" target="_blank">https://review.openstack.org/#/c/128940</a><br>
><br>
> Unfortunately, for some reason I really don't understand, Sergey is<br>
> being required to create an API extension called "os-server-tags" in<br>
> order to add the server tag functionality to the API. The patch<br>
> implements the 2.4 Nova API microversion, though, as you can see from<br>
> this part of the patch:<br>
><br>
> <a href="https://review.openstack.org/#/c/128940/43/nova/api/openstack/compute/plugins/v3/server_tags.py" target="_blank">https://review.openstack.org/#/c/128940/43/nova/api/openstack/compute/plugins/v3/server_tags.py</a><br>
><br>
><br>
> What is the point of creating a new "plugin"/API extension for this new<br>
> functionality? Why can't we just modify the<br>
> nova/api/openstack/compute/server.py Controller.show() method and<br>
> decorate it with a 2.4 microversion that adds a "tags" attribute to the<br>
> returned server dictionary?<br>
><br>
> <a href="https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L369" target="_blank">https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L369</a><br>
><br>
><br>
> Because we're using an API extension for this new server tags<br>
> functionality, we are instead having the extension "extend" the server<br>
> dictionary with an "os-server-tags:tags" key containing the list of<br>
> string tags.<br>
><br>
> This is ugly and pointless. We don't need to use API extensions any more<br>
> for this stuff.<br>
><br>
> A client knows that server tags are supported by the 2.4 API<br>
> microversion. If the client requests the 2.4+ API, then we should just<br>
> include the "tags" attribute in the server dictionary.<br>
><br>
> Similarly, new microversion API functionality should live in a module,<br>
> as a top-level (or subcollection) Controller in<br>
> /nova/api/openstack/compute/, and should not be in the<br>
> /nova/api/openstack/compute/plugins/ directory. Why? Because it's not a<br>
> plugin.<br>
><br>
> Why are we continuing to use these awkward, messy, and cumbersome API<br>
> extensions?<br>
><br>
> Please, I am begging the Nova core team. Let us stop this madness. No<br>
> more API extensions.<br>
<br>
</div></div>Agreed, the current extensions list exists to explain the base v2<br>
functionality. I think we should consider that frozen and deprecated as<br>
of v2.1 as we have a better way to express features.<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br></font></span></blockquote><div><br><br></div><div>So I think we can a microversion ASAP to remove support for /extensions. Obviously we'll need to keep the actual code<br></div><div>to support v2.1 for quite a while though.<br><br></div><div>I think we still want some fields in the controller like we do because we want to automate JSON-HOME/Schema stuff (maybe not sure)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>