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. 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) > -- > Sean Dague > http://dague.net > > > __________________________________________________________________________ > 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
