Open Stack

----- Original Message -----
> From: "Christopher Yeoh" <cbkyeoh at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Monday, March 9, 2015 1:04:15 PM
> Subject: Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?
> 
> 
> 
> On Mon, Mar 9, 2015 at 10:08 PM, John Garbutt < john at johngarbutt.com > wrote:
> 
> 
> 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.
> 
> 
> If the only thing server-tags did was to add a parameter then we wouldn't
> need a new extension,
> but its not, it adds another resource with associated actions
> 
> 
> Maybe we need a more modular way of expressing the extension within
> the same file?
> 
> 
> I think servers.py is simply to big. Its much harder to read and debug than
> any other plugin just because of its size - or
> maybe I just need a 50" monitor :) I'd rather ensure functionality common
> server-tags and the API is kept together rather than
> spread through servers.py
> 
No, it isn't.
It is bellow 2k line. I usually use low level tools even for python related debugging.
For ex.: strace, gdb..
With the extension I get lot of files which may be involved may be not.
This causes me additional headache, because more difficult to see which file
is involved. After an strace I usually know what is the mistake, I just need to find
it in the code.
I do not like when I had to open more than 3 files, after I see what went wrong.
I some cases I use gdb, just to get python stack traces just before the first incorrect
step is detected, in other cases git grep is sufficient.

Actually for me the extensions increases the required monitor number,
some cases I also need to use more complicated approaches.
I tied lot of python profiler tool as well, but there is no single all cases win version,
extra custom hack is required in many cases to get something close what I want.

> 
> > 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.
> 
> Yep, there is I think no reason except to support /extensions for now and I
> don't really think its worth having
> two entry points, one for modules which will appear in /extensions and one
> for modules which won't appear
> in /extensioins. The overhead is low. We should warn v2.1+ users to ignore
> /extensions unless they are legacy v2 api users
> and they should remove their use of it anyway as soon as they get off v2.1.
> They key to dumping it all is
> when people tell us v2.1 really is behaving just like v2 so we can remove the
> old v2 code and then later have a microversion that
> doesn't support /extensions. I hope all the json-home stuff is in by then :-)
> 
> 
> 
> >> 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.
> 
> 
> Yea we already did a lot of that in v3 and had to separate some of them out
> again for v2.1 (argh!). Others we have just faked (eg you load module "X"
> you get module "Y" for free which doesn't really exist anymore - but only
> for those that we were very sure that the extension only existed to notify
> users that some functionality was present.
> 
> 
> 
> Thanks,
> John
> 
> __________________________________________________________________________
> 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
> 
> 
> __________________________________________________________________________
> 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
>