00:00:30 <cyeoh> #startmeeting nova-api
00:00:31 <openstack> Meeting started Fri Mar 28 00:00:30 2014 UTC and is due to finish in 60 minutes.  The chair is cyeoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:00:34 <openstack> The meeting name has been set to 'nova_api'
00:00:48 <cyeoh> Hi - who do we have here today?
00:00:56 <mrda> \o
00:01:00 <masayukig> o/
00:01:18 <changsimon> hi
00:01:21 <tinoue> hi
00:01:43 <cyeoh> ok, let's get started
00:01:52 <ken1ohmichi> hi
00:01:56 <cyeoh> #topic v2 on v3 POC
00:02:12 <cyeoh> #link https://etherpad.openstack.org/p/NovaV2OnV3POC
00:02:50 <cyeoh> I went through most of the POC patches this week and added a couple of things I think we need to address that weren't on the list before
00:03:04 <cyeoh> the first is header translation
00:03:25 <cyeoh> Some parts of the API like images and I think servers return some links in headers
00:03:58 <cyeoh> they probably have v2 or v3 urls in them which we may need to translate - that I think should be pretty straightforward
00:04:13 <cyeoh> will need to a better audit though - images should not be an issue since we don't support that in v3 anyway
00:04:22 <cyeoh> but the servers ones might be.
00:04:43 <cyeoh> The other was extension listing which we sort of knew about already but wasn't on the list
00:05:08 <cyeoh> will need to have a /extensions for v2.1 which looks like v2 but based on what v3 extensions are currently loaded
00:05:33 <cyeoh> because some extensions have been collapsed into others in v3 we'll have less flexibility, but I think that will be ok
00:05:56 <cyeoh> will need to check with the cloud providers, but they are all IIRC fairly straightforward stuff
00:06:24 <cyeoh> we will also most likely need a slightly different "core" for v2.1 and probably a separate whitelist/blacklist for V2.1
00:06:32 <cyeoh> I'm happy to work on those if no one else wants to
00:06:48 <cyeoh> other than that I'm pretty happy with the state of the POC patches
00:07:07 <cyeoh> ken1ohmichi: would you like to talk about what you've been looking at re: testing?
00:07:18 <ken1ohmichi> yes
00:07:42 <ken1ohmichi> now most Poc APIs are implemented.
00:07:52 <ken1ohmichi> and now we need to test it on tempest
00:08:13 <ken1ohmichi> but I dont have a good way with tempest
00:08:22 <cyeoh> so are we going to need to port the images API in order to be able to test?
00:08:37 <cyeoh> and maybe volumes?
00:08:44 <ken1ohmichi> yes, right and flavor also is necessary.
00:08:45 <cyeoh> I should be able to do those pretty quickly if required
00:09:04 <cyeoh> ok, so flavor just needs the conversion decorators?
00:09:30 <ken1ohmichi> yes, and need the other tlanslation ways
00:09:38 <ken1ohmichi> for flavors.
00:10:00 <cyeoh> #action need images/volumes/flavors support for POC
00:10:02 <ken1ohmichi> now "list flavors" API works on v2.1 API
00:10:19 <ken1ohmichi> but "create a flavor" API does not work. I will dig it more later
00:10:54 <cyeoh> ok I'll put images and volumes POC support on my todo list. Should have it done by end of monday
00:10:57 <ken1ohmichi> that is my today main work
00:11:11 <ken1ohmichi> cyeoh: thanks!
00:11:23 <cyeoh> np
00:11:54 <cyeoh> so is there anything else we need to talk about v2.1?
00:11:59 <ken1ohmichi> that's all from me
00:12:45 <cyeoh> oh just one other thing I remembered. We'll eventually need separate sections in setup.cfg for loading the plugins for v2.1 and v3
00:13:09 <cyeoh> but I think that should be pretty straightforward too
00:13:33 <cyeoh> #topic api response validation in tempest
00:13:53 <cyeoh> from what I've seen it looks pretty good there - lots of stuff has merged or is merging
00:14:05 <cyeoh> ken1ohmichi: do you have an estimate of what sort of coverage we have so far?
00:14:31 <ken1ohmichi> cyeoh: yes, that is in a good progress
00:15:04 <ken1ohmichi> coverage is almost 10% for APIs
00:15:35 <ken1ohmichi> and a lot of patches still are in review:) https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/nova-api-attribute-test,n,z
00:15:43 <cyeoh> #link https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/nova-api-attribute-test,n,z
00:16:02 <ken1ohmichi> thanks for much review effort, all
00:16:12 <cyeoh> yes there is a lot of patches to be reviewed for those who are interested in doing tempest reviews. And they're pretty straightforward to review too :-)
00:17:06 <ken1ohmichi> and I hope some PoC target API patches will be merged soon.
00:17:10 <cyeoh> so one question I had about the testing we are doing there is if we also need to check headers
00:17:33 <cyeoh> because they do essentially form part of the API too
00:17:48 <cyeoh> oh so re: POC target API patches - do you mean the Nova ones?
00:17:50 <ken1ohmichi> cyeoh: you mean "links" attribute?
00:18:28 <ken1ohmichi> cyeoh: no, tempest ones.
00:18:43 <ken1ohmichi> for example, https://review.openstack.org/#/c/81222/
00:18:55 <ken1ohmichi> but it has been approved already:-)
00:19:06 <cyeoh> ken1ohmichi: oh I see :-)
00:19:52 <ken1ohmichi> the other one is https://review.openstack.org/#/c/80923/
00:19:55 <cyeoh> if there are ones that you think need priority reviewing maybe you could list them on an etherpad somewhere? I'm just sort of looking at the api attribute ones from oldest at the moment
00:20:18 <cyeoh> ok I'll have a look at that one today
00:20:20 <ken1ohmichi> that is a good idea,  I will do it later.
00:20:26 <cyeoh> ken1ohmichi: thx!
00:20:39 <cyeoh> re: headers - I was thinking more of situations like where the servers create_image call
00:20:47 <cyeoh> returns a Location header
00:21:14 <cyeoh> which is a url to (I think) glance where it is created
00:21:47 <cyeoh> eg. see nova/api/openstack/compute/servers.py:1473
00:22:08 <cyeoh> The value can chance without an issues, but the header name has to stay the same
00:22:36 <cyeoh> I really don't know why its returned in an header rather than in the body, but that's what we have to live with
00:23:03 <ken1ohmichi> oh, I see.
00:23:12 <ken1ohmichi> that is an important point.
00:23:44 <cyeoh> I think it probably makes sense to add that as something that can be specified in the json schema?
00:24:15 <ken1ohmichi> yes, I feel we can do it in Tempest.
00:24:29 <cyeoh> excellent :-)
00:24:47 <ken1ohmichi> I will consider it later:)
00:25:13 <cyeoh> sounds great. Anyone have anything else they want to talk about on the tempest attribute testing?
00:25:57 <cyeoh> #topic V3 API sdk port
00:26:07 <cyeoh> mrda: would you like to talk about this?
00:26:13 <mrda> cyeoh: sure
00:26:28 <mrda> I've been looking at porting libcloud to support v3
00:26:45 <mrda> libcloud is a cross-cloud library written in python
00:27:04 <mrda> I've had a few issues getting it going with devstack, but that's resolved now.
00:27:31 <mrda> It looks like adding in support for v3 won't be too hard.  I'll be working on this as a priority over this next week.
00:27:48 <cyeoh> cool - do you know how many backend clouds it supports?
00:28:04 <mrda> quite a few - and most of the majors
00:28:37 <mrda> I think there's some 20+ different clouds, and the api is generic
00:28:45 <mrda> so should be a good test
00:29:09 <cyeoh> yep, that sounds like a really good example
00:29:28 <mrda> just checking - over 30 providers
00:30:02 <cyeoh> that's a lot so presumably they've done a fair amount of work to keep the provider specific stuff well isolated...
00:30:31 <mrda> yes, you can grab a list of providers, and query/spin up using a generic interface
00:30:45 <mrda> so it won't cover all of v3 - only the bits that are generic across clouds
00:31:23 <mrda> I'll put my fork up on github so anyone can see the changes I've had to make to get it working
00:31:45 <cyeoh> yea that would be really good to be able to show everyone, especially at summit
00:32:00 <mrda> no probs - any questions or suggestions most welcome :)
00:32:12 <cyeoh> mrda: port all the SDKs :-)
00:32:26 <mrda> that's not a suggestion
00:32:30 <mrda> :)
00:32:33 <cyeoh> :-)
00:32:57 <cyeoh> ok anything else on SDKs?
00:33:13 <mrda> not from me
00:33:32 <cyeoh> #topic summit proposals
00:33:50 <cyeoh> I've put in 3:
00:33:59 <cyeoh> #link http://summit.openstack.org/cfp/details/147
00:34:07 <cyeoh> #link http://summit.openstack.org/cfp/details/149
00:34:15 <cyeoh> #link http://summit.openstack.org/cfp/details/148
00:34:28 <ken1ohmichi> cyeoh: great:)
00:34:28 <cyeoh> basically a cross project API one, a V3 API one and a V2.1 on V3 one
00:34:52 <mrda> cyeoh: +1
00:35:08 <cyeoh> so if you think there is stuff missing from them that we need to talk about at summit, please comment one them
00:35:46 <cyeoh> Is there anything else that anyone thinks would need a separate additional session?
00:36:31 <cyeoh> ken1ohmichi: I wasn't sure if you wanted to do something around json schema in tempest?
00:36:48 <cyeoh> given the discussion on the mailing list about json schema for negative testing
00:37:02 <cyeoh> its sort of affects Nova too if we want Nova to produce the schema in the long term..
00:37:04 <ken1ohmichi> cyeoh: uh, I don't have one item now.
00:37:37 <ken1ohmichi> cyeoh: yes, right. and I guess David also is interested in.
00:37:57 <alex_xu> cyeoh, in v3, except nova-network, neutron-network is also need finish in Juno, it's need to talk about at summit?
00:38:31 <cyeoh> alex_xu: so I've included the tasks api work in the v3 session too
00:38:38 <cyeoh> as I think we want to nail down the API
00:38:58 <cyeoh> I'd also like to discuss the criteria we will use for being able to release the V3 API.
00:39:11 <cyeoh> so there is no confusion over what the community wants
00:39:24 <alex_xu> cyeoh, ok, i got it
00:39:46 <mrda> cyeoh: Agreed, I think getting some form of agreement on what constitutes v3 being releasable is extremely important.
00:40:20 <cyeoh> yea I don't want to have another giant email discussion in J-3 ;-)
00:40:38 <ken1ohmichi> cyeoh: agree:-)
00:40:54 <alex_xu> yeah :)
00:40:55 <masayukig> +1
00:41:20 <ken1ohmichi> cyeoh: all working items for v3 are on http://summit.openstack.org/cfp/details/149 ?
00:41:29 <ken1ohmichi> nova-network support
00:41:34 <ken1ohmichi> Tasks API
00:41:38 <ken1ohmichi> python novaclient v2/v3 stability
00:41:42 <ken1ohmichi> all ?
00:42:06 <cyeoh> yea, that's all I could remember at the time I was writing it. If you think of any others please add them in the comments
00:42:25 <cyeoh> looks like I can update the description
00:42:47 <ken1ohmichi> cyeoh: OK, I will see it carefully later.
00:43:06 <cyeoh> nova-network is a big chunk of work, but other than that the V3 API is pretty much complete.
00:43:18 <cyeoh> It might be worth doing a pass over the API during Juno just to look at some other consistency issues
00:43:34 <cyeoh> dansmith brought up the issue of date/time stamps not being consistent across the API
00:43:43 <cyeoh> and we should probably fix that while we have the opportunity
00:43:58 <cyeoh> (some apparently use UTC others use localtime)
00:44:09 <dansmith> not just that
00:44:12 <dansmith> it's format too
00:44:14 <ken1ohmichi> cyeoh: yes, many issues has/will be fixed in v3.
00:44:29 <dansmith> isotime, str(datetime), str(datetime_with_tz), and some others
00:44:34 <cyeoh> dansmith: ok yea we should definitely fix that too while we still can.
00:44:49 <cyeoh> dansmith: heh whatever tool the programmer had handy in his head at the time ;-)
00:44:58 <dansmith> it's so inconsistent,
00:45:10 <dansmith> it looks  like we were *trying* to come up with new ways :)
00:45:19 <mrda> dansmith: +1 :)
00:45:21 <cyeoh> dansmith: hahaha :-)
00:45:49 <cyeoh> I think we should report everything in swatch time
00:46:14 <cyeoh> #open discussion
00:46:23 <cyeoh> #topic open discussion
00:46:46 <cyeoh> ok was there anything else we should talk about?
00:46:51 <changsimon> cyeoh: yes
00:47:04 <changsimon> I've recently committed a fix and it got merged
00:47:18 <changsimon> it's my first fix, now i'm looking for something new to work on
00:47:31 <changsimon> can you suggest an area that I should look at and help out?
00:48:10 <cyeoh> well perhaps you'd like to look at the use of date/time stamps in the V3 API?
00:48:35 <changsimon> I can do that, can you point out where I can locate details of this requirement?
00:48:38 <cyeoh> to see what sort of variation we have, and can start doing patches to convert them all to use UTC instead?
00:48:53 <changsimon> ok
00:49:03 <cyeoh> so I don't think its been written down, but basically the issue is that in various parts of the API
00:49:14 <cyeoh> we have fields which return date/time stamps
00:49:34 <cyeoh> and we just need to ensure that the format is consistent across the whole API and its in UTC rather than localtime of the server
00:50:02 <changsimon> I see, I can take a look at that.
00:50:27 <cyeoh> changsimon: thanks!
00:50:33 <changsimon> :)
00:50:53 <cyeoh> does anyone have anything else they'd like to talk about?
00:51:43 <ken1ohmichi> nothing from me, I have gotten many tasks already ;-)
00:51:48 <cyeoh> ok. looks like that's it for today then. Thank you everyone for attending
00:51:52 <cyeoh> ken1ohmichi:  :-)
00:52:09 <ken1ohmichi> thanks
00:52:12 <cyeoh> #endmeeting