2015-03-09 20:36 GMT+09:00 Christopher Yeoh <cbky...@gmail.com>: > > > On Mon, Mar 9, 2015 at 9:35 PM, Sean Dague <s...@dague.net> wrote: >> >> On 03/07/2015 07:31 PM, Jay Pipes wrote: >> > 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. >> >> Agreed, the current extensions list exists to explain the base v2 >> functionality. I think we should consider that frozen and deprecated as >> of v2.1 as we have a better way to express features. >> >> -Sean >> > > > So I think we can a microversion ASAP to remove support for /extensions. > Obviously we'll need to keep the actual code > to support v2.1 for quite a while though.
big +1 for removing /extensions. Now /extensions API provides available futures on each cloud services, but provided information is difficult to use. In addition, there is a ugly trick in the implementation for providing v2 full compatible information. > I think we still want some fields in the controller like we do because we > want to automate JSON-HOME/Schema stuff (maybe not sure) yeah, JSON-Home is one of standard ways for providing this kind of information. The nova-spec is https://review.openstack.org/#/c/130715/ I hope it will be implement in Liberty. Thanks Ken Ohmichi --- : https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/plugins/v3/extension_info.py#L29 __________________________________________________________________________ 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