Open Stack

2015-03-10 3:37 GMT+08:00 Jay Pipes <jaypipes at gmail.com>:

> On 03/08/2015 08:10 AM, Alex Xu wrote:
>
>> Thanks for Jay point this out! If we have agreement on this and document
>> it, that will be great for guiding developer how to add new API.
>>
>> I know we didn't want extension for API. But I think we still
>> need modularity. I don't think we should put everything in a single
>> file, that file will become huge in the future and hard to maintenance.
>>
>
> I don't think everything should be in a single file either. In fact, I've
> never advocated for that.
>
>  We can make the 'extension' not configurable. Replace 'extension' with
>> another name, deprecate the extension info api int he future.... But
>> that is not mean we should put everything in a file.
>>
>
> 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?
>
>  For modularity, we need define what should be in a separated module(it
>> is extension now.) There are three cases:
>>
>> 1. Add new resource
>>      This is totally worth to put in a separated module.
>>
>
> Agreed.
>
>  2. Add new sub-resource
>>      like server-tags, I prefer to put in a separated module, I don't
>> think put another 100 lines code in the servers.py is good choice.
>>
>
> Agreed, which is exactly what I said in my email:
>
> "Similarly, new microversion API functionality should live in a
> module, as a top-level (or subcollection) Controller in
> /nova/api/openstack/compute/, and should not be in the
> /nova/api/openstack/compute/plugins/ directory. Why? Because it's
> not a plugin."
>
>  3. extend attributes and methods for a existed resource
>>     like add new attributes for servers, we can choice one of existed
>> module to put it in. Just like this patch
>> https://review.openstack.org/#/c/155853/
>>     But for servers-tags, it's sub-resource, we can put it in its-own
>> module.
>>
>
> Agreed, and that's what I put in my email.
>
>  If we didn't want to support extension right now, we can begin from not
>> show servers-tags in extension info API first. That means extension info
>> is freeze now. We deprecated the extension info api in later version.
>>
>
> 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/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.
>
>
Ok, I think I see you now. Forgive me for any misunderstood.

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.

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 https://review.openstack.org/162912

For the modularity, I put in separated patch
https://review.openstack.org/162913

Those two things I think we can discussion them separately. (Emm.....This
is kind of evidence about I misunderstood you)



> In addition to that, for the changes to the main GET /servers/{server_id}
> resource, use microversions to decorate the /nova/api/openstack/compute/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.
>
> Best,
> -jay
>
>  Thanks
>> Alex
>>
>> 2015-03-08 8:31 GMT+08:00 Jay Pipes <jaypipes at gmail.com
>> <mailto:jaypipes at gmail.com>>:
>>
>>     Hi Stackers,
>>
>>     Now that microversions have been introduced to the Nova API (meaning
>>     we can now have novaclient request, say, version 2.3 of the Nova API
>>     using the special X-OpenStack-Nova-API-Version HTTP header), is
>>     there any good reason to require API extensions at all for *new*
>>     functionality.
>>
>>     Sergey Nikitin is currently in the process of code review for the
>>     final patch that adds server instance tagging to the Nova API:
>>
>>     https://review.openstack.org/#__/c/128940
>>     <https://review.openstack.org/#/c/128940>
>>
>>     Unfortunately, for some reason I really don't understand, Sergey is
>>     being required to create an API extension called "os-server-tags" in
>>     order to add the server tag functionality to the API. The patch
>>     implements the 2.4 Nova API microversion, though, as you can see
>>     from this part of the patch:
>>
>>     https://review.openstack.org/#__/c/128940/43/nova/api/__
>> openstack/compute/plugins/v3/__server_tags.py
>>     <https://review.openstack.org/#/c/128940/43/nova/api/
>> openstack/compute/plugins/v3/server_tags.py>
>>
>>     What is the point of creating a new "plugin"/API extension for this
>>     new functionality? Why can't we just modify the
>>     nova/api/openstack/compute/__server.py Controller.show() method and
>>     decorate it with a 2.4 microversion that adds a "tags" attribute to
>>     the returned server dictionary?
>>
>>     https://github.com/openstack/__nova/blob/master/nova/api/__
>> openstack/compute/servers.py#__L369
>>     <https://github.com/openstack/nova/blob/master/nova/api/
>> openstack/compute/servers.py#L369>
>>
>>     Because we're using an API extension for this new server tags
>>     functionality, we are instead having the extension "extend" the
>>     server dictionary with an "os-server-tags:tags" key containing the
>>     list of string tags.
>>
>>     This is ugly and pointless. We don't need to use API extensions any
>>     more for this stuff.
>>
>>     A client knows that server tags are supported by the 2.4 API
>>     microversion. If the client requests the 2.4+ API, then we should
>>     just include the "tags" attribute in the server dictionary.
>>
>>     Similarly, new microversion API functionality should live in a
>>     module, as a top-level (or subcollection) Controller in
>>     /nova/api/openstack/compute/, and should not be in the
>>     /nova/api/openstack/compute/__plugins/ directory. Why? Because it's
>>     not a plugin.
>>
>>     Why are we continuing to use these awkward, messy, and cumbersome
>>     API extensions?
>>
>>     Please, I am begging the Nova core team. Let us stop this madness.
>>     No more API extensions.
>>
>>     Best,
>>     -jay
>>
>>     ____________________________________________________________
>> __________________
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:
>>     OpenStack-dev-request at lists.__openstack.org?subject:__unsubscribe
>>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>> >
>>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>>
>> ____________________________________________________________
>> ______________
>> 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
>>
>>
> __________________________________________________________________________
> 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/20150310/a85e146c/attachment.html>