<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-03-10 3:37 GMT+08:00 Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 03/08/2015 08:10 AM, Alex Xu wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Thanks for Jay point this out! If we have agreement on this and document<br>
it, that will be great for guiding developer how to add new API.<br>
<br>
I know we didn't want extension for API. But I think we still<br>
need modularity. I don't think we should put everything in a single<br>
file, that file will become huge in the future and hard to maintenance.<br>
</blockquote>
<br></span>
I don't think everything should be in a single file either. In fact, I've never advocated for that.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
We can make the 'extension' not configurable. Replace 'extension' with<br>
another name, deprecate the extension info api int he future.... But<br>
that is not mean we should put everything in a file.<br>
</blockquote>
<br></span>
I didn't say that in my email. I'm not sure where you got the impression I want to put everything in one file?<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
For modularity, we need define what should be in a separated module(it<br>
is extension now.) There are three cases:<br>
<br>
1. Add new resource<br>
This is totally worth to put in a separated module.<br>
</blockquote>
<br></span>
Agreed.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2. Add new sub-resource<br>
like server-tags, I prefer to put in a separated module, I don't<br>
think put another 100 lines code in the servers.py is good choice.<br>
</blockquote>
<br></span>
Agreed, which is exactly what I said in my email:<span class=""><br>
<br>
"Similarly, new microversion API functionality should live in a<br>
module, as a top-level (or subcollection) Controller in<br>
/nova/api/openstack/compute/, and should not be in the<br>
/nova/api/openstack/compute/<u></u>plugins/ directory. Why? Because it's<br>
not a plugin."<br>
<br>
</span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
3. extend attributes and methods for a existed resource<br>
like add new attributes for servers, we can choice one of existed<br>
module to put it in. Just like this patch<br>
<a href="https://review.openstack.org/#/c/155853/" target="_blank">https://review.openstack.org/#<u></u>/c/155853/</a><br>
But for servers-tags, it's sub-resource, we can put it in its-own<br>
module.<br>
</blockquote>
<br></span>
Agreed, and that's what I put in my email.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If we didn't want to support extension right now, we can begin from not<br>
show servers-tags in extension info API first. That means extension info<br>
is freeze now. We deprecated the extension info api in later version.<br>
</blockquote>
<br></span>
I don't understand what you're saying here. Could you elaborate? What I am asking for is for new functionality (like the server-tags subcollection resource), just add a new module called /nova/api/openstack/compute/<u></u>server_tags.py, create a Controller object in that file with the new server tags resource, and don't use any of the API extensions framework whatsoever.<br>
<br></blockquote><div><br></div><div>Ok, I think I see you now. Forgive me for any misunderstood.</div><div><br></div><div>Actually I mean we can freeze and depreciated the '/extensions' API at here. We can freeze the '/extensions' API now, didn't show server-tags extension in that API.</div><div><br></div><div>Follow the discussion, I think there is two things related to 'extension'. One is '/extensions' API, another one is plugin framework. And I added devref about that <a href="https://review.openstack.org/162912">https://review.openstack.org/162912</a></div><div><br></div><div>For the modularity, I put in separated patch <a href="https://review.openstack.org/162913">https://review.openstack.org/162913</a> </div><div><br></div><div>Those two things I think we can discussion them separately. (Emm.....This is kind of evidence about I misunderstood you)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In addition to that, for the changes to the main GET /servers/{server_id} resource, use microversions to decorate the /nova/api/openstack/compute/<u></u>servers.py.Controller.show() method for 2.4 and add a "tags" key to the dict (note: NOT a "os-server-tags:tags" key) returned by GET /servers/{server_id}. No use of API extensions needed.<br>
<br>
Best,<br>
-jay<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
Thanks<br>
Alex<br>
<br>
2015-03-08 8:31 GMT+08:00 Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a><br></span>
<mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>>:<span class=""><br>
<br>
Hi Stackers,<br>
<br>
Now that microversions have been introduced to the Nova API (meaning<br>
we can now have novaclient request, say, version 2.3 of the Nova API<br>
using the special X-OpenStack-Nova-API-Version HTTP header), is<br>
there any good reason to require API extensions at all for *new*<br>
functionality.<br>
<br>
Sergey Nikitin is currently in the process of code review for the<br>
final patch that adds server instance tagging to the Nova API:<br>
<br></span>
<a href="https://review.openstack.org/#__/c/128940" target="_blank">https://review.openstack.org/#<u></u>__/c/128940</a><span class=""><br>
<<a href="https://review.openstack.org/#/c/128940" target="_blank">https://review.openstack.org/<u></u>#/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<br>
from this part of the patch:<br>
<br></span>
<a href="https://review.openstack.org/#__/c/128940/43/nova/api/__openstack/compute/plugins/v3/__server_tags.py" target="_blank">https://review.openstack.org/#<u></u>__/c/128940/43/nova/api/__<u></u>openstack/compute/plugins/v3/_<u></u>_server_tags.py</a><span class=""><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/<u></u>#/c/128940/43/nova/api/<u></u>openstack/compute/plugins/v3/<u></u>server_tags.py</a>><br>
<br>
What is the point of creating a new "plugin"/API extension for this<br>
new functionality? Why can't we just modify the<br></span>
nova/api/openstack/compute/__<u></u>server.py Controller.show() method and<span class=""><br>
decorate it with a 2.4 microversion that adds a "tags" attribute to<br>
the returned server dictionary?<br>
<br></span>
<a href="https://github.com/openstack/__nova/blob/master/nova/api/__openstack/compute/servers.py#__L369" target="_blank">https://github.com/openstack/_<u></u>_nova/blob/master/nova/api/__<u></u>openstack/compute/servers.py#_<u></u>_L369</a><span class=""><br>
<<a href="https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L369" target="_blank">https://github.com/openstack/<u></u>nova/blob/master/nova/api/<u></u>openstack/compute/servers.py#<u></u>L369</a>><br>
<br>
Because we're using an API extension for this new server tags<br>
functionality, we are instead having the extension "extend" the<br>
server dictionary with an "os-server-tags:tags" key containing the<br>
list of string tags.<br>
<br>
This is ugly and pointless. We don't need to use API extensions any<br>
more 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<br>
just include the "tags" attribute in the server dictionary.<br>
<br>
Similarly, new microversion API functionality should live in a<br>
module, as a top-level (or subcollection) Controller in<br>
/nova/api/openstack/compute/, and should not be in the<br></span>
/nova/api/openstack/compute/__<u></u>plugins/ directory. Why? Because it's<span class=""><br>
not a plugin.<br>
<br>
Why are we continuing to use these awkward, messy, and cumbersome<br>
API extensions?<br>
<br>
Please, I am begging the Nova core team. Let us stop this madness.<br>
No more API extensions.<br>
<br>
Best,<br>
-jay<br>
<br></span>
______________________________<u></u>______________________________<u></u>__________________<span class=""><br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br></span>
OpenStack-dev-request@lists.__<a href="http://openstack.org?subject:__unsubscribe" target="_blank"><u></u>openstack.org?subject:__<u></u>unsubscribe</a><br>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@<u></u>lists.openstack.org?subject:<u></u>unsubscribe</a>><br>
<a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-dev</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a>><span class=""><br>
<br>
<br>
<br>
<br>
______________________________<u></u>______________________________<u></u>______________<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.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</span></blockquote><div class=""><div class="h5">
<br>
______________________________<u></u>______________________________<u></u>______________<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.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>