[openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

Christopher Yeoh cbkyeoh at gmail.com
Mon Mar 9 11:36:37 UTC 2015


On Mon, Mar 9, 2015 at 9:35 PM, Sean Dague <sean at 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-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/20150309/0980ac4f/attachment.html>


More information about the OpenStack-dev mailing list