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.

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 <jaypi...@gmail.com
<mailto:jaypi...@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@lists.__openstack.org?subject:__unsubscribe
    <http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to