Open Stack

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. 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.

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.
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.
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.

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.

Thanks
Alex

2015-03-08 8:31 GMT+08:00 Jay Pipes <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
>
> 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
>
> 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
>
> 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://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/20150308/4ec172ab/attachment.html>