00:01:24 <cyeoh> #startmeeting nova api
00:01:25 <openstack> Meeting started Fri Sep 19 00:01:24 2014 UTC and is due to finish in 60 minutes.  The chair is cyeoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:01:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:28 <openstack> The meeting name has been set to 'nova_api'
00:01:37 <cyeoh> Hi! Who is here today?
00:01:42 <oomichi> hello!
00:01:42 <alex_xu> good morning!
00:01:46 <eliqiao> hi cyeoh.
00:01:59 <gmann> hi
00:02:31 <cyeoh> ok let's get started.
00:02:35 <cyeoh> #topic v2 on v3 api
00:03:11 <cyeoh> So nothing merging now given the rc is so close but I think we should continue spending some time reviewing the patches we do have
00:03:23 <cyeoh> eg. there's a bunch of new network related ones
00:03:36 <cyeoh> so when Kilo opens we can merge very quickly
00:03:54 <oomichi> cyeoh: that means revewing with WIPs?
00:04:02 <cyeoh> everyone ok with that? (Just ignore the -2's/WIPs on the patches)
00:04:15 <cyeoh> oomichi: yea I don't think that will hurt will it?
00:04:15 <alex_xu> I'm ok
00:04:30 <oomichi> cyeoh: nice for me
00:04:31 <cyeoh> The only patch I have that is WIP that is truly WIP is the extension info one
00:04:52 <gmann> sounds good
00:04:54 <eliqiao> remove WIP of network proxy patch?
00:05:12 <cyeoh> eliqiao: don't remove the WIP or they might get -2'd
00:05:30 <cyeoh> but when you have time do review any of the v2-on-v3 patches even if they are marked WIP
00:05:42 <eliqiao> okay
00:05:50 <cyeoh> so hopefully we can get them all cleaned up a ready to merge
00:06:11 <oomichi> cyeoh: we need to post spec for v2.1 kilo
00:06:38 <cyeoh> oomichi: I was hoping to just sneak them in :-)
00:06:49 <cyeoh> I guess we could just repost the same spec
00:06:58 <oomichi> on https://review.openstack.org/#/c/116699/ discussion, the v2.1 spec will be approved soon after kilo open
00:07:36 <oomichi> cyeoh: yes, right. enough to repost the same spec for kilo, maybe
00:08:16 <cyeoh> oomichi: it should be - we'll keep microversions separate
00:08:48 <oomichi> cyeoh: yea, we should separate it for avoiding slow progress :)
00:08:58 <cyeoh> will ask PTL & John - perhaps can just get an exemption since its continuing work
00:09:37 <oomichi> cyeoh: sounds nice
00:10:01 <cyeoh> anything else on v2 on v3? (will talk about microversions separately)
00:10:31 <gmann> cyeoh: V2 has 'os-volume_attachments' resource to attach/detach/swap volume and V3 has server action ('attach' etc) for the same
00:11:01 <gmann> as we need to port 'os-volume_attachments' for V2.1, do we keep V3 version also or remove that?
00:11:01 <cyeoh> gmann: hrm v2 doesn't have the attach server action?
00:12:10 <cyeoh> did we miss os-volume_attachments?
00:12:33 <gmann> i think no, V2 has 'os-volume_attachments' no server action.
00:12:43 <oomichi> cyeoh: maybe we missed it.
00:12:48 <gmann> yes, we missed to port os-volume_attachment
00:13:08 * cyeoh is just looking through his git tree
00:13:26 <alex_xu> we can move attach/detach code as os-volume_attachment
00:14:48 <gmann> alex_xu: yes but as in microversion we might need those API implemented as server action, should not we keep those also and provide os-volume_attachments for backward compatibility
00:16:08 <alex_xu> gmann, I just think of share the code attach/detach/swap and os-volume_attachment will complex, so maybe we introduce those action back will more easy
00:16:44 <alex_xu> but I'm ok with both way
00:17:01 <cyeoh> is the implementation exactly the same? For some reason I remember talking about this before
00:17:13 <cyeoh> and I think I ended up deliberately removing the attachment code from volumes.py
00:18:49 <cyeoh> ok anyone I think this needs more looking into....
00:18:56 <alex_xu> a lot of different in input/output
00:19:00 <cyeoh> can work it out offline I think
00:19:17 <gmann> yes, request response is main diff
00:19:31 <alex_xu> yes, can file a bug then track it
00:20:54 <gmann> ok, i will release a WIP patch (by keeping V3 server action too) and then we can go for better direction.
00:20:57 <cyeoh> yea I think we'll need to re-implement it again
00:20:58 <gmann> is it ok?
00:21:32 <cyeoh> yep thats fine. I think eventually we should just drop the v3 version
00:21:39 <alex_xu> I'm fine too
00:21:49 <gmann> ok.
00:21:52 <cyeoh> gmann: thanks for picking that up!
00:22:11 <cyeoh> ok anything else for v2 on v3 api
00:22:28 <gmann> while testing i found some more extension missed like disk_config too.
00:22:51 <gmann> I will keep updating etherpad about my finding.
00:23:03 <cyeoh> gmann: argh :-( Could you put them on the etherpad? And then someone can pick them up.
00:23:04 <cyeoh> thanks!
00:23:12 <oomichi> gmann: nice work!
00:23:12 <alex_xu> gmann, great job!
00:23:24 <gmann> sure thanks
00:23:42 <cyeoh> hrm config_drive does seem to be ported?
00:24:10 <cyeoh> unless for some reason its not loading properly?
00:24:51 <cyeoh> anyway can look into it more - but it does appear that there is a v3 version which looks like it implements everything the v2 one does
00:24:55 <oomichi> yeah, config_drive seems to be ported with I8a0d50efcda6fcd12971a41505127de5987eec18
00:25:25 <gmann> yes, but need to look. is it same with disk_config
00:25:28 <cyeoh> on sorry I misread - you said disk_config
00:25:31 <oomichi> gmann: NotFound config_drive with Tempest?
00:26:14 <cyeoh> gmann: yes you're right we're missing disk_config
00:26:19 <gmann> error is 'OS-DCF:diskConfig' not in server body
00:26:37 <oomichi> gmann: sorry, that is a part of SchedulerHints
00:27:05 <oomichi> Ieed7619f3cb310b25d157ebb07f24468aea1af9d is right commit id.
00:28:05 <gmann> i have added disk_config in etherpad. i will try to release today.
00:28:27 <cyeoh> gmann: cool :-)
00:29:02 <oomichi> gmann: thanks, I will see it.
00:29:10 <cyeoh> #topic microversions
00:29:27 <cyeoh> Alex has some ideas he's mailed out about microversions.
00:29:36 <cyeoh> alex_xu: do you want to paste think link to your blog post in here?
00:29:56 <alex_xu> There is the blog post
00:29:56 <alex_xu> #link http://soulxu.github.io/blog/2014/09/12/one-option-for-nova-api/
00:30:25 <cyeoh> alex_xu: sorry I haven't read the revised version yet but will look at it soon
00:30:37 <alex_xu> cyeoh, thanks!
00:31:14 <cyeoh> just wondering if anyone else had anything they want to talk about it?
00:31:37 <cyeoh> I think it's also fine if we just discuss it via email as well....
00:32:14 <oomichi> alex_xu: nice doc :-)
00:32:26 <oomichi> cyeoh: I agree, we need time for it.
00:32:33 <alex_xu> oomichi, thanks, I also hope got your suggestion
00:32:54 <cyeoh> oomichi: ok, fair enough. I know I need to think about it all a bit more myself....
00:33:35 <oomichi> maybe it would be nice to discuss it on -dev ml
00:33:48 <gmann> yes, that was really nice doc and POC. I also need to go through it completely. ll provide my input if any
00:34:02 <oomichi> many people will join into the discussion.
00:34:04 <alex_xu> gmann, cool, thanks
00:34:21 <cyeoh> oomichi: yes we should. alex_xu: do you want to start off an email thread?
00:34:43 <alex_xu> cyeoh, sure
00:34:46 <cyeoh> I still have strong reservations about parts. eg I don't want a method per version
00:34:47 <oomichi> the doc is already nice for discussing it :-)
00:35:11 <cyeoh> because I think that's too much duplicated code, but we can talk about that more
00:35:17 <alex_xu> but the doc isn't good for comment...
00:35:55 <alex_xu> cyeoh, yea, a lot of thing need more think about
00:36:00 <cyeoh> yea a nova-spec is better for discussion but I think its worth sending it out for some general discussions first
00:36:44 <oomichi> yeah, right. we need many opinions. -dev is nice for getting them.
00:37:10 <alex_xu> yes, send as nova-spec when we ensure it is ready
00:37:58 <oomichi> alex_xu: thanks
00:38:04 <alex_xu> oomichi, np
00:38:41 <cyeoh> #topic open discussion
00:39:05 <cyeoh> ok, is there anything else people would like to talk about?
00:40:29 <oomichi> one point
00:40:51 <oomichi> can we add v2.1 endpoint setting to devstack now?
00:41:30 <oomichi> as yesterday maling list discussion, v2.1 endpoint is not registered to keystone yet.
00:41:43 <cyeoh> oomichi: I don't see why not
00:42:08 <cyeoh> it'd be useful for testing
00:42:14 <oomichi> cyeoh: my concern was experimental v2.1 now.
00:42:53 <oomichi> but it is necessary to test/use v2.1 with nova command.
00:43:22 <gmann> yes, i have to change locally each time i test V2.1 :)
00:43:29 <oomichi> I will try it later anyway :-)
00:44:02 <cyeoh> oomichi: i think its fine with it experimental. keystone folks are probably going to complain about yet another versioned endpoint though!
00:44:08 <cyeoh> since that's not how its supposed to work
00:44:22 <oomichi> gmann: right, in many cases I use curl command for v2.1 testing. that is not useful for me:-(
00:45:29 <oomichi> cyeoh: nice info, yeah will do it :-)
00:46:36 <cyeoh> ok is there anything else?
00:47:09 <oomichi> yeah, good for me now :)
00:47:21 <gmann> nothing from my side
00:47:41 <alex_xu> that's for me
00:48:03 <alex_xu> that's all for me
00:48:36 <cyeoh> ok thanks everyone!
00:48:50 <cyeoh> #endmeeting