[openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

Christopher Yeoh cbkyeoh at gmail.com
Tue Mar 24 05:31:28 UTC 2015


On Tue, Mar 24, 2015 at 5:45 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> On Tue, Mar 10, 2015 at 09:52:14PM +1030, Christopher Yeoh wrote:
> > On Mon, 09 Mar 2015 16:14:21 -0400
> > Sean Dague <sean at dague.net> wrote:
> >
> > > On 03/09/2015 03:37 PM, Jay Pipes wrote:
> > > > On 03/08/2015 08:10 AM, Alex Xu 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.
> > > >>
> > > >> I know we didn't want extension for API. But I think we still
> > > >> need modularity. I don't think we should put everything in a single
> > > >> file, that file will become huge in the future and hard to
> > > >> maintenance.
> > > >
> > > > I don't think everything should be in a single file either. In fact,
> > > > I've never advocated for that.
> > > >
> > > >> We can make the 'extension' not configurable. Replace 'extension'
> > > >> with another name, deprecate the extension info api int he
> > > >> future.... But that is not mean we should put everything in a file.
> > > >
> > > > I didn't say that in my email. I'm not sure where you got the
> > > > impression I want to put everything in one file?
> > > >
> > > >> 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.
> > > >
> > > > Agreed.
> > > >
> > > >> 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.
> > > >
> > > > Agreed, which is exactly what I said in my email:
> > > >
> > > > "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."
> > > >
> >
> > Ok so I'm getting confused about what we're disagreeing about then.
>
> I wasn't disagreeing with you. I was disagreeing with Alex Xu :) Perhaps
> your mail client was confusing you?
>
> > However, the first microversion change
> > https://review.openstack.org/#/c/140313/32 is one case where we didn't
> > need to create a new extension, relying only on microversions to add a
> > new parameter to the response, whereas server tags does add a new
> > conroller (os-server-tags) which is non trivia so I think it does. Do
> > we disagree about that?
>
> The server tags patch does add more functionality to the API, for sure.
> But, as I've written about in this thread, there's no reason at all that
> it needed to use the extension framework. It could better have been
> written as a simple Controller object in a new file in
> /nova/api/openstack/compute/server_tags.py, with no use of the
> extension mechanism whatsoever.
>
> > btw in a situation now where (I think) we are saying we are not going
> > to do any work for 3rd parties to add their own API plugins and have a
> > well planned API we don't need the prefixes as we don't need the prefix
> > on parameter names as there won't be name clashes without us realising
> > during testing. And we certainly don't need the os- prefix is the
> > plugin alias, but we do neeed them unique across the API I believe
> > because of the way we store information about them.
>
> Right. There won't be any more name clashes if we don't allow API
> extensions any more. Which is what I'm asking for.
>
> > > >> 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/
> > > >>     But for servers-tags, it's sub-resource, we can put it in
> > > >> its-own module.
> > > >
> > > > Agreed, and that's what I put in my email.
> > > >
> > > >> If we didn't want to support extension right now, we can begin
> > > >> from not show servers-tags in extension info API first. That means
> > > >> extension info is freeze now. We deprecated the extension info api
> > > >> in later version.
> >
> > It can be surpressed from /extensions by adding it to the suppress list
> > in the extensions code. Probably a good idea to stop v2.1+microversion
> > code REST API users not accidentally relying on it.
>
> I don't want it suppressed. I want the use of API extensions and the
> extension framework(s) to be completely dropped for all future
> API-affecting work.
>
> > > > I don't understand what you're saying here. Could you elaborate?
> > > > What I am asking for is for new functionality (like the server-tags
> > > > subcollection resource), just add a new module called
> > > > /nova/api/openstack/compute/server_tags.py, create a Controller
> > > > object in that file with the new server tags resource, and don't
> > > > use any of the API extensions framework whatsoever.
> > > >
> > > > In addition to that, for the changes to the main GET
> > > > /servers/{server_id} resource, use microversions to decorate the
> > > > /nova/api/openstack/compute/servers.py.Controller.show() method for
> > > > 2.4 and add a "tags" key to the dict (note: NOT a
> > > > "os-server-tags:tags" key) returned by GET /servers/{server_id}. No
> > > > use of API extensions needed.
> >
> > So I that's doabe but I think if we compared to the two wsgi.extends
> > is cleaner and less code and we have to have the separate module file
> > anyway for the controller. Can discuss this more later...
>
> As mentioned above, I'm quite happy with a separate module for the
> server tags Controller. What I'm not happy about is forcing the server
> tags stuff to be implemented as an API "plugin" using the extensions
> framework, because the extensions framework no longer has any point.
>
> > Incidentally as has been mentioned before we need new names for the
> > API and where the files need to live needs cleaning up. For example v3
> > and v2.1 needs to be worked out of the directory paths.This clenaup not
> > on involves but directly  affects the all the related unit and
> > functional tests. Nor should we have contrib or should v2 live directly
> > in in nova/api/openstack/compute. But we also need a name for v2.1
> > microversions and should spend some time on that (does api modules work
> > for anyone?)
>
> Why do we need new names for stuff? Just put everything in
> /nova/api/openstack/compute/ and be done with it. It doesn't have to be
> all in one single file, of course. But there's just no reason to
> continue using the extensions framework for anything nor putting new
> functionality into any of the files in
> /nova/api/openstack/compute/plugins/.
>
> > I think this dicussion indicates we should start with a bit of planning
> > first rather than just jump in and start shuffling this around now.
> > Work out what we want the final thing to look like so we can see what
> > the dependencies look like and minimise the number of times that files
> > get shuffled around. It is also likely to be one of those patches that
> > is a real pain to merge without some well timed +2 coordination.
>
> I haven't asked to shuffle anything around. I'm simply asking that *new*
> functionality that touches the API:
>
>  * be placed in /nova/api/openstack/compute/ files
>  * not use the extensions framework (i.e. the plugin stuff)
>
> That's it. No shuffling required right now. Happy to have discussions in
> Vancouver about cleaning directories up in Liberty.
>
> > Perhaps its something we can talk about at the Nova API meeting this
> > week?
>
> I'm game for this week :) Sorry, missed last week.
>
>
Ok, lets put it down on the agenda for the Nova API meeting this week. I
suspect there's still some concerns of yours I'm missing and hopefully an
irc meeting will help clear that up.  I'm still of the mind though that
priority has to during the rest of this cycle given to tech debt reduction
- primarily test consolidation and directory cleanups. This sort of work
always gets puts last which causes us issues at other points of the
development cycle. Even just moving new code to nova/api/openstack/compute
is not straightforwards because the old v2 code is scattered throughout
where we want new files. And even if there isn't a direct nameclash its
really confusing for anyone wanting to read the new code.

So I'm really pushing for cleanup first. directory reorg then everything
can go where it belongs long term. Anyway can discuss more at the meeting
this week.



> > Also, apologies in advance but over at least the next couple of weeks I
> > may be slow in replying on irc/email.
>
> No worries at all, Chris!
>
> -jay
>
> >
> > Regards,
> >
> > Chris
> >
> > > So possibly another way to think about this is our prior signaling of
> > > what was supported by Nova was signaled by the extension list. Our
> > > code was refactored into a way that supported optional loading by
> > > that unit.
> > >
> > > As we're making things less optional it probably makes sense to evolve
> > > the API code tree to look more like our REST resource tree. Yes, that
> > > means servers.py ends up being big, but it is less confusing that all
> > > servers related code is in that file vs all over a bunch of other
> > > files.
> > >
> > > So I'd agree that in this case server tags probably should just be in
> > > servers.py. I also think long term we should do some "plugin collapse"
> > > for stuff that's all really just features on one resource tree so that
> > > the local filesystem code structure looks a bit more like the REST
> > > url tree.
> > >
> > >     -Sean
> > >
> >
> >
> >
> __________________________________________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150324/245413ed/attachment.html>


More information about the OpenStack-dev mailing list