Open Stack

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



> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150309/9159eee8/attachment.html>