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[1] 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

---
[1]: 
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

Reply via email to