<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 9, 2015 at 10:08 PM, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I think I agree with Jay here, but let me explain...<br>
<span class=""><br>
On 8 March 2015 at 12:10, Alex Xu <<a href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>> wrote:<br>
> Thanks for Jay point this out! If we have agreement on this and document it,<br>
> that will be great for guiding developer how to add new API.<br>
<br>
</span>+1<br>
<br>
Please could you submit a dev ref for this?<br>
<br>
We can argue on the review, a bit like this one:<br>
<a href="https://github.com/openstack/nova/blob/master/doc/source/devref/policy_enforcement.rst" target="_blank">https://github.com/openstack/nova/blob/master/doc/source/devref/policy_enforcement.rst</a><br>
<span class=""><br>
> For modularity, we need define what should be in a separated module(it is<br>
> extension now.) There are three cases:<br>
><br>
> 1. Add new resource<br>
>     This is totally worth to put in a separated module.<br>
<br>
</span>+1<br>
<span class=""><br>
> 2. Add new sub-resource<br>
>     like server-tags, I prefer to put in a separated module, I don't think<br>
> put another 100 lines code in the servers.py is good choice.<br>
<br>
</span>-1<br>
<br>
I hate the idea of show instance extension code for version 2.4 living<br>
separately to the rest of the instance show logic, when it really<br>
doesn't have to.<br>
<br>
It feels too heavyweight in its current form.<br>
<br></blockquote><div><br></div><div>If the only thing server-tags did was to add a parameter then we wouldn't need a new extension,<br></div><div>but its not, it adds another resource with associated actions<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe we need a more modular way of expressing the extension within<br>
the same file?<br>
<span class=""><br></span></blockquote><div><br></div><div>I think servers.py is simply to big. Its much harder to read and debug than any other plugin just because of its size - or<br></div><div>maybe I just need a 50" monitor :) I'd rather ensure functionality common server-tags and the API is kept together rather than <br></div><div>spread through servers.py<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 3. extend attributes and methods for a existed resource<br>
>    like add new attributes for servers, we can choice one of existed module<br>
> to put it in. Just like this patch <a href="https://review.openstack.org/#/c/155853/" target="_blank">https://review.openstack.org/#/c/155853/</a><br>
<br>
</span>+1<br>
<br>
I wish it was easier to read, but I hope thats fixable long term.<br>
<span class=""><br>
> 2015-03-08 8:31 GMT+08:00 Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>:<br>
</span><span class="">>> 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 the<br>
>> special X-OpenStack-Nova-API-Version HTTP header), is there any good reason<br>
>> to require API extensions at all for *new* functionality.<br>
<br>
</span>As above, a new "resource" probably should get a new "plugins/v3" module right?<br>
<br>
It feels (at worst) borderline in the os-server-tags case, due to the<br>
extra actions.<br>
<span class=""><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 decorate<br>
>> it with a 2.4 microversion that adds a "tags" attribute to the returned<br>
>> server dictionary?<br>
>><br>
</span><span class="">>> Similarly, new microversion API functionality should live in a module, as<br>
>> a top-level (or subcollection) Controller in /nova/api/openstack/compute/,<br>
>> and should not be in the /nova/api/openstack/compute/plugins/ directory.<br>
>> Why? Because it's not a plugin.<br>
<br>
</span>Everything is a "plugin" in v3, no more distinction between core vs<br>
plugin. It needs renaming really.<br>
<br>
It should look just like servers, I guess, which is a top level item:<br>
<a href="https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/plugins/v3/servers.py" target="_blank">https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/plugins/v3/servers.py</a><br>
<span class=""><br>
>> Why are we continuing to use these awkward, messy, and cumbersome API<br>
>> extensions?<br>
<br>
</span>We certainly should never be forced to add an extension to advertise<br>
new functionality anymore.<br>
<br>
Its a big reason why I want to see the API micro-versions succeed.<br></blockquote><div><br></div><div>Yep, there is I think no reason except to support /extensions for now and I don't really think its worth having<br></div><div>two entry points, one for modules which will appear in /extensions and one for modules which won't appear<br></div><div>in /extensioins. The overhead is low. We should warn v2.1+ users to ignore /extensions unless they are legacy v2 api users<br></div><div>and they should remove their use of it anyway as soon as they get off v2.1. They key to dumping it all is<br></div><div>when people tell us v2.1 really is behaving just like v2 so we can remove the old v2 code and then later have a microversion that<br></div><div>doesn't support /extensions. I hope all the json-home stuff is in by then :-)<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>> Please, I am begging the Nova core team. Let us stop this madness. No more<br>
>> API extensions.<br>
<br>
</span>Lets try get something agreed in devref, so we are ready to go when<br>
Liberty opens.<br>
<br>
It would be nice to look at ways to fold back the existing extensions<br>
into the main code. I know there are v2.0 compatibility issues there,<br>
but I think/hope thats mostly cosmetic at this point.<br>
<br></blockquote><div><br></div><div>Yea we already did a lot of that in v3 and had to separate  some of them out again for v2.1 (argh!). Others we have just faked (eg you load module "X" you get module "Y" for free which doesn't really exist anymore - but only for those that we were very sure that the extension only existed to notify users that some functionality was present.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
John<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div></div>