00:00:37 #startmeeting nova api 00:00:37 Meeting started Fri Aug 15 00:00:37 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:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:00:40 The meeting name has been set to 'nova_api' 00:00:49 Hi - who have we got here today? 00:00:54 \o/ 00:01:00 Hi 00:01:09 hi all 00:01:54 ok let's get started 00:02:03 #topic v21_on_v3 00:02:16 So I think we all know about the worklist 00:02:24 #link https://etherpad.openstack.org/p/v2_1_WorkList 00:03:02 I think we have everything we need to work on in the etherpad, but please add more entries if you think something is missing 00:04:24 Also I wanted to give everyone the opportunity to speak up if they think the implementation details of the approach we're taking on doing the conversion/port is wrong 00:04:35 before too much is merged :-) 00:04:52 or simply if you have any questions of why we're doing some things the way we are 00:05:45 anyone? 00:05:48 we will have second round works, like share api sample tests, policy stuff, we will doing those in K release? 00:06:24 What we expected to finish in J? 00:07:01 alex_xu: yes we'll need to look at those. I'm not sure about the api sample tests but regardless we need to think about how we'll keep sharing in the context of microversions 00:07:04 (if we can) 00:07:19 So we have less than a week to feature proposal freeze 00:07:31 so I think cleanup patches will be deferred to K 00:08:03 the priority should be getting up patches before next thu (I think it is thu) 00:08:04 cyeoh, yea, sharing for microversion is complex 00:08:22 cyeoh: sounds good. when is the code freeze for J? 00:08:54 so feature freeze is Sep 4 00:09:02 proposal freeze is 21st august 00:09:43 we can *probably* get exceptions for the proposal freeze, but it'd be better to get at patch up if possible before 21st Aug 00:10:00 even if it requires a bit more cleanup afterwards 00:11:13 cyeoh: we have lot of patches out. I think my have to pace up the review also. 00:11:33 I see lots of plugins are took by someone, but no patches out... :( 00:12:02 I think we need to tell them we are in a hurry. 00:12:04 gmann_: yep that would be really helpful so when a core comes along they can just +2 it 00:12:34 I will try to do today as much as possible. 00:12:39 eliqiao: yes, if anyone has reserved a plugin and don't think they'll have the time, please remove your name so someone else can 00:13:14 gmann_, yes, I think we won't get too much review bandwidth, we better review them by ourselve first 00:13:16 (or just double check that you have put a link to the review on etherpad which shows that there is a patchset up) 00:14:12 but if you don't think you can get the plugin done by next wednesday, please release it and someone else will pick it up 00:14:48 #topic open discussion 00:15:27 any patches that people would like to be reviewed urgently (eg something that a lot of other patches depend on?) 00:16:20 cyeoh, I see lots of patches[1] need to modify 00:16:20 doc/v3/api_samples/all_extensions/* 00:16:21 nova/tests/integrated/v3/api_samples/all_extensions/* 00:16:21 00:16:21 there woule be confict ... when merge these patches... 00:16:21 [1] 00:16:21 https://review.openstack.org/#/c/114107/ 00:16:21 https://review.openstack.org/#/c/114112/ 00:16:22 etc.. 00:17:03 eliqiao: oh yes, sorry I meant to reply to your email 00:17:31 yes, the server extension related patches may well conflict quite a bit 00:17:45 I think most of them will merge though 00:17:52 unless the lines changes really are adjacent 00:18:13 there's no great solution 00:18:28 I think its probably best to start initially putting them all in parallel 00:18:46 and then rebase on master if you need to as they merge 00:19:25 if we get to the state where we're sure they're all ok. We can make a string of dependencies and rebase patches so they are dependent on each other 00:19:55 okay, thanks cyeoh, good idea. 00:20:04 then they will all merge at once - but its not probably worth doing that until they're at the stage where we're sure they're ok as otherwise there will be lots of rebasing 00:20:43 ok. I didn't have anything else to talk about 00:20:46 ooh, I have one 00:20:48 https://review.openstack.org/#/c/113947/ 00:20:48 :) 00:21:11 dansmith: oh nice! 00:21:19 want :-) 00:22:02 it's more efficient for the fault case, 00:22:11 which I think is what you're hitting normally, 00:22:31 and I guess we need to have more discussion about whether we get better about being very defensive about instances going away underneath us 00:22:32 dansmith: yea, thats where we've been hitting it in the gate 00:22:39 cool 00:23:15 yea I agree we need a wider discussion about that 00:23:24 I'm kinda mixed 00:23:37 as long as we have soft deletes, I kidna feel like objects shouldn't explode 00:23:50 but also, not deleting stuff seems to be widely despised 00:23:55 the API layer really isn't structured to be handle that sort of circumstance because when it started out we were just passing around a dict of information 00:24:06 yeah 00:24:21 well, I guess that's a problem if we move to actually deleting things 00:24:27 but whatever, that's a different bridge 00:25:34 anyway, my shameless link baiting is over :) 00:26:17 thanks :) It's a race we've had for quite a while now in the API but I haven't had time to get a good fix for it - and its very very rare 00:27:02 well, you waited too late to shame me apparently :) 00:27:23 well, not too late, but too long 00:28:26 heh. last time (for pci_devices) we just patched it, but that was because it broke the gate. This time its been failing, but not actually causing the test to fail. Anyway it'll all be good now :-) 00:29:07 did anyone else have anything they wanted to talk about? Otherwise we can all have a short meeting and get back to coding :-) 00:29:40 gmann: nothing from my side :) 00:29:50 nothing from me too 00:30:23 ok, thanks everyone! 00:30:29 #endmeeting