Open Stack

Hi,

2015-03-09 20:38 GMT+09:00 John Garbutt <john at johngarbutt.com>:
> On 8 March 2015 at 12:10, Alex Xu <soulxu at gmail.com> wrote:
>> 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.
>
> +1
>
> Please could you submit a dev ref for this?
>
> We can argue on the review, a bit like this one:
> https://github.com/openstack/nova/blob/master/doc/source/devref/policy_enforcement.rst
>
>> 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.
>
> +1

yeah, +1 for simple/readable code.

>> 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.
>
> -1
>
> I hate the idea of show instance extension code for version 2.4 living
> separately to the rest of the instance show logic, when it really
> doesn't have to.
>
> It feels too heavyweight in its current form.
>
> Maybe we need a more modular way of expressing the extension within
> the same file?

That would depend on how size of a file.
I'd like to avoid a single huge file for reviewing a patch on firefox.
Sometimes, loading time is long due to the size(especially nova/compute/api.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?
>>>
>>> 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.
>
> Everything is a "plugin" in v3, no more distinction between core vs
> plugin. It needs renaming really.

+1, but we need to remove current v2(not v2.1) code before doing that.
To reduce cost for maintaining both v2 and v2.1 code, we will use v2.1
code only in long term and v2 code will be removed.
Now v2 code lives under /nova/api/openstack/compute and
/nova/api/openstack/compute/contrib, and v2.1 code does under
/nova/api/openstack/compute/plugins/v3.
So current directory structure would be easy to remove v2 code in
long term.

>>> Why are we continuing to use these awkward, messy, and cumbersome API
>>> extensions?
>
> We certainly should never be forced to add an extension to advertise
> new functionality anymore.
>
> Its a big reason why I want to see the API micro-versions succeed.

+1
I also don't want to add dummy extensions just for advertising a new
functionalities more.
When I saw the code first time, I was confused due to them.

Thanks
Ken Ohmichi