Open Stack

Hi,

I think I agree with Jay here, but let me explain...

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

> 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?

> 3. extend attributes and methods for a existed resource
>    like add new attributes for servers, we can choice one of existed module
> to put it in. Just like this patch https://review.openstack.org/#/c/155853/

+1

I wish it was easier to read, but I hope thats fixable long term.

> 2015-03-08 8:31 GMT+08:00 Jay Pipes <jaypipes at gmail.com>:
>> 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.

As above, a new "resource" probably should get a new "plugins/v3" module right?

It feels (at worst) borderline in the os-server-tags case, due to the
extra actions.

>> 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.

It should look just like servers, I guess, which is a top level item:
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/plugins/v3/servers.py

>> 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.

>> Please, I am begging the Nova core team. Let us stop this madness. No more
>> API extensions.

Lets try get something agreed in devref, so we are ready to go when
Liberty opens.

It would be nice to look at ways to fold back the existing extensions
into the main code. I know there are v2.0 compatibility issues there,
but I think/hope thats mostly cosmetic at this point.

Thanks,
John