12:00:03 #startmeeting nova api 12:00:05 Meeting started Fri Jul 3 12:00:03 2015 UTC and is due to finish in 60 minutes. The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:00:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:00:08 The meeting name has been set to 'nova_api' 12:00:20 Is there anybody at here today? 12:00:37 yep. I am in ;) 12:00:45 Jeffrey4l: hey, welcome! 12:00:53 hi 12:01:00 u r welcome~ 12:01:00 gmann: hi 12:01:14 US in holiday~ 12:01:47 wait one more min to say if there is more people 12:01:48 yea, there are having fireworks today :) 12:02:03 gmann: cool, fireworks 12:02:07 gmann: are you at US? 12:02:20 no, m in Tokyo 12:02:36 gmann: woo~ cool, with Ken'ichi 12:02:47 yea :). 12:03:01 I think no more people at here~ 12:03:10 gmann: do you have anything want me help? 12:03:45 I guess this one https://review.openstack.org/#/c/197822/ 12:03:53 alex_xu: not much just that one 12:04:04 gmann: I'm on your side 12:04:32 hope jaypipes and sdague can give some suggestion for that patch also 12:05:03 alex_xu: yea, because if we do not fix that in v2.1 then v2.1 will be different always 12:05:11 good morning all. 12:05:16 gmann: agree with that 12:05:23 alex_xu: yea, and we can move based on conclusion 12:05:24 jaypipes: hey, good morning 12:05:36 jaypipes: good morning 12:05:39 alex_xu: just caffeining myself :) 12:05:45 gmann: mornin! 12:05:53 jaypipes: there is argument on https://review.openstack.org/#/c/197822/, hope get you suggestion 12:06:26 we think that needn't bump version, because we promise v2.1 equal to v2. 12:06:32 * jaypipes reads 12:06:37 jaypipes: just added you in https://review.openstack.org/#/c/197822/ review 12:06:59 John point it out, he think the v2.1 already release, anything change or bug fix need version bump 12:07:56 but this bug isn't existed in v2, it because the mistake when port v2 to v2.1, and we break the contract 'v2.1 equal to v2' 12:08:27 * alex_xu think maybe the comment in patch better than his poor English explain... 12:08:50 alex_xu: nope, I understand you completely, no worries. /me still thinking on this :) 12:08:58 yea, we think we can fix that as bug in v2.1 on master and kilo to have same as v2 12:09:15 yea, we should backport this fix also 12:09:38 I have patch up for kilo too - https://review.openstack.org/#/c/197850/ 12:10:45 gmann: I think I agree with johnthetubaguy on this one. Really, if we are changing the returned response body in any way -- even if we are trying to just provide compat with v2.0 -- we should add a microversion so that clients will be able to know the difference of returned results between a server running 2.6 and a server running 2.7 (if this patch adds a 2.7 microversion) 12:11:34 jaypipes: emm..that means all the users depend on that API will be broken after switch to v2.1 12:11:49 jaypipes: yea but users moving from v2 to v2.1 will break if we donot fix it in v2.1 base API 12:12:47 reminder: we have contract say: v2.1 equal to v2 except strict validation. 12:13:02 well, thats not quite correct 12:13:03 because this is not newly added attribute just bug while porting v2.1 12:13:08 that was the intent 12:13:15 but we shipped v2.1 already 12:13:16 gmann, alex_xu: yes, that is correct. but if we fix it in v2.1 base, then clouds that are deployed without that fix will be indifferentiable from one with the fix. 12:13:19 if we don't fix that. The contract is changed: 'v2.1 almost equal to v2 except strict validation and removing that field' 12:13:25 jaypipes: +1 12:13:38 alex_xu: that is absolutely correct. 12:14:20 so the problem is, we really don't want to break the API version rules, its a bad example to set, I think 12:14:22 jaypipes: emm...yea, that is problem, that is based on there is already have user begin to user v2.1. and we release v2.1 now, we can't ensure there isn't any user using it 12:15:11 jaypipes: if we backport that in kilo too and after Clouds upgrade it will be fine. it would break them as it is addition of attribute. 12:15:12 for context, we assume an API is deployed and in use, pretty much[1], as soon as its merged 12:15:34 [1] we maybe have 24 hours to revert, if we pretend, and we really screwed up 12:16:08 gmann: people deploy clouds from any commit in the Nova tree, we have to keep that in mind here 12:16:09 ok 12:16:39 so I think there is another thing can make it better, we shouldn't let the extension API in v2.1 return that extension 12:16:41 johnthetubaguy: humm yea... 12:17:30 the v2 API should depend on extesion API to know whether that field existed or not. If we didn't let extension API return that extension, then v2 API user didn't find that extension existed in the deploy then won't use it 12:17:41 so the v2 API will avoid to break 12:18:00 and then we fix it by bump version 12:18:45 alex_xu: but hiding extension in v2 again introduce backward incompatibility 12:19:35 gmann: no, the v2 api have contract, some extended attribute should be detected by extension whether load in that deployement 12:20:00 alex_xu: oh, I see what you are saying, stop v2.1 pretending it has the missing extensions, thats a smart move 12:20:25 johnthetubaguy: yea, we just need change this line https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/plugins/v3/extension_info.py#L70 12:20:59 we didn't return ExtendedVIFNet extension in the extension API 12:21:44 gmann: does make sense to you? 12:22:00 gmann: v2 api user won't be break anymore 12:22:20 also resolve johnthetubaguy and jaypipes's concern 12:22:46 so clouds moving to v2.1 can be told that this is missing extension in v2.1 and they can disable that in v2 deployed one to have same env if they move from v2 to v2.1? 12:22:48 alex_xu: so, we could look at exposing the extra extension when you request /v2, but we can leave that as a separate task 12:23:02 gmann: precisely correct. 12:23:41 ohhk 12:24:06 that's sounds clever and good to me 12:24:22 johnthetubaguy: sorry, I didn't get you 12:24:26 gmann: cool :) 12:25:03 johnthetubaguy: you means later adding that as extension in v2.1 when requesting /v2 ? 12:25:26 gmann: something like that, yeah 12:25:52 johnthetubaguy: I prefer a totally new name for that field, probably without that extension alias prefix 12:25:59 so v2.1 in v2 compact mode starts returning the extra bit we added into v2.1 at v2.6 12:26:08 alex_xu: in v2.6, sure 12:26:27 alex_xu: that certainly complicates things though... 12:26:44 gmann: maybe we just leave it out of the v2.0 compat mode for now, and see how we go 12:27:09 hmm, that feels bad, when I say it like that 12:27:36 ok, got agremenet, so let's move on ? 12:27:55 #link https://review.openstack.org/#/c/148509/ 12:28:18 the author want me raise this up, because whether need top-level element, I think it's ok now. 12:28:26 jaypipes: do you still have concern for that ^ 12:28:41 ok, so we will add that attribute as version bump 12:28:52 and modify v2.1 extension list too? 12:29:23 sorry for jumping on previous topic :) 12:29:33 gmann: yes 12:29:34 alex_xu: so, I think my last review on that was basically saying "I could go either way" :) whatever the API WG decides is fine, and if they want to use a top-level key in the returned dict because it's consistent with how nova is now, that's fine with me. 12:29:47 cool 12:30:09 FWIW, local consistency seems worth while 12:30:09 jaypipes: cool! 12:30:41 the last one, there is clarify for remove v3 spec 12:30:43 #link https://review.openstack.org/#/c/193589/ 12:31:13 johnthetubaguy: would you like help on that, it's easy, and the point is raised by you before 12:32:19 alex_xu: reviewed. 12:32:21 +1 12:32:30 cool, that looks good 12:32:30 jaypipes: thanks :) 12:32:37 so this subgroup wants that merged right? 12:32:43 johnthetubaguy: cool, thanks 12:33:01 johnthetubaguy: this week...only me at here 12:33:24 johnthetubaguy: I can push other people to give point next week, then I will bother you later~ 12:33:25 so I am thinking of treating this subgroups approval as a +2, and just merging it 12:33:29 to get people unblocked 12:33:51 sensible or crazy pants? 12:34:26 * alex_xu can help a +2? ooh~ 12:34:48 anyways, I will add my +2, it looks good 12:35:01 johnthetubaguy: cool, thanks 12:35:23 if that not being merged starts blocking people, let me know 12:35:46 the last last thing...help review microversion client patch https://review.openstack.org/152569 the spec alrready merged! 12:36:04 johnthetubaguy: ok 12:36:14 and last few policy patch https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-api-policy-final-part,n,z 12:36:31 anymore question? any open? then I will close meeting early~ 12:37:02 thanks folks for all the hard work on the API 12:37:09 its crazy important for Nova 12:37:16 :) 12:37:18 func test merging patches - https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:merge_sample_tests,n,z 12:37:31 gmann: yea ^ also just left few patch 12:37:33 few left please review on your free time 12:37:45 there are all on the etherpad of doom I guess? 12:37:51 alex_xu: yea after those just clean up patches i will puch 1 or 2 12:38:02 gmann: that's worth to put in this etherpad https://etherpad.openstack.org/p/liberty-nova-priorities-tracking 12:38:08 +1 12:38:11 sure 12:38:38 what is puch... 12:38:53 sorry *push :) 12:39:05 ok... 12:39:10 my typo always kills me 12:39:18 close the meeting 3.. 12:39:23 2... 12:39:26 1... 12:39:34 #endmeeting