12:00:03 <alex_xu> #startmeeting nova api
12:00:05 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:08 <openstack> The meeting name has been set to 'nova_api'
12:00:20 <alex_xu> Is there anybody at here today?
12:00:37 <Jeffrey4l> yep. I am in ;)
12:00:45 <alex_xu> Jeffrey4l: hey, welcome!
12:00:53 <gmann> hi
12:01:00 <Jeffrey4l> u r welcome~
12:01:00 <alex_xu> gmann: hi
12:01:14 <alex_xu> US in holiday~
12:01:47 <alex_xu> wait one more min to say if there is more people
12:01:48 <gmann> yea, there are having fireworks today :)
12:02:03 <alex_xu> gmann: cool, fireworks
12:02:07 <alex_xu> gmann: are you at US?
12:02:20 <gmann> no, m in Tokyo
12:02:36 <alex_xu> gmann: woo~ cool, with Ken'ichi
12:02:47 <gmann> yea :).
12:03:01 <alex_xu> I think no more people at here~
12:03:10 <alex_xu> gmann: do you have anything want me help?
12:03:45 <alex_xu> I guess this one https://review.openstack.org/#/c/197822/
12:03:53 <gmann> alex_xu: not much just that one
12:04:04 <alex_xu> gmann: I'm on your side
12:04:32 <alex_xu> hope jaypipes and sdague can give some suggestion for that patch also
12:05:03 <gmann> alex_xu: yea, because if we do not fix that in v2.1 then v2.1 will be different always
12:05:11 <jaypipes> good morning all.
12:05:16 <alex_xu> gmann: agree with that
12:05:23 <gmann> alex_xu: yea, and we can move based on conclusion
12:05:24 <alex_xu> jaypipes: hey, good morning
12:05:36 <gmann> jaypipes: good morning
12:05:39 <jaypipes> alex_xu: just caffeining myself :)
12:05:45 <jaypipes> gmann: mornin!
12:05:53 <alex_xu> jaypipes: there is argument on https://review.openstack.org/#/c/197822/, hope get you suggestion
12:06:26 <alex_xu> we think that needn't bump version, because we promise v2.1 equal to v2.
12:06:32 * jaypipes reads
12:06:37 <gmann> jaypipes: just added you in https://review.openstack.org/#/c/197822/ review
12:06:59 <alex_xu> John point it out, he think the v2.1 already release, anything change or bug fix need version bump
12:07:56 <alex_xu> 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 <jaypipes> alex_xu: nope, I understand you completely, no worries. /me still thinking on this :)
12:08:58 <gmann> yea, we think we can fix that as bug in v2.1 on master and kilo to have same as v2
12:09:15 <alex_xu> yea, we should backport this fix also
12:09:38 <gmann> I have patch up for kilo too - https://review.openstack.org/#/c/197850/
12:10:45 <jaypipes> 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 <alex_xu> jaypipes: emm..that means all the users depend on that API will be broken after switch to v2.1
12:11:49 <gmann> 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 <alex_xu> reminder: we have contract say: v2.1 equal to v2 except strict validation.
12:13:02 <johnthetubaguy> well, thats not quite correct
12:13:03 <gmann> because this is not newly added attribute just bug while porting v2.1
12:13:08 <johnthetubaguy> that was the intent
12:13:15 <johnthetubaguy> but we shipped v2.1 already
12:13:16 <jaypipes> 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 <alex_xu> 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 <johnthetubaguy> jaypipes: +1
12:13:38 <jaypipes> alex_xu: that is absolutely correct.
12:14:20 <johnthetubaguy> 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 <alex_xu> 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 <gmann> 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 <johnthetubaguy> for context, we assume an API is deployed and in use, pretty much[1], as soon as its merged
12:15:34 <johnthetubaguy> [1] we maybe have 24 hours to revert, if we pretend, and we really screwed up
12:16:08 <johnthetubaguy> gmann: people deploy clouds from any commit in the Nova tree, we have to keep that in mind here
12:16:09 <alex_xu> ok
12:16:39 <alex_xu> 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 <gmann> johnthetubaguy: humm yea...
12:17:30 <alex_xu> 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 <alex_xu> so the v2 API will avoid to break
12:18:00 <alex_xu> and then we fix it by bump version
12:18:45 <gmann> alex_xu: but hiding extension in v2 again introduce backward incompatibility
12:19:35 <alex_xu> gmann: no, the v2 api have contract, some extended attribute should be detected by extension whether load in that deployement
12:20:00 <johnthetubaguy> 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 <alex_xu> 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 <alex_xu> we didn't return ExtendedVIFNet extension in the extension API
12:21:44 <alex_xu> gmann: does make sense to you?
12:22:00 <alex_xu> gmann: v2 api user won't be break anymore
12:22:20 <alex_xu> also resolve johnthetubaguy and jaypipes's concern
12:22:46 <gmann> 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 <johnthetubaguy> 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 <jaypipes> gmann: precisely correct.
12:23:41 <gmann> ohhk
12:24:06 <gmann> that's sounds clever and good to me
12:24:22 <alex_xu> johnthetubaguy: sorry, I didn't get you
12:24:26 <alex_xu> gmann: cool :)
12:25:03 <gmann> johnthetubaguy: you means later adding that as extension in v2.1 when requesting /v2 ?
12:25:26 <johnthetubaguy> gmann: something like that, yeah
12:25:52 <alex_xu> johnthetubaguy: I prefer a totally new name for that field, probably without that extension alias prefix
12:25:59 <johnthetubaguy> so v2.1 in v2 compact mode starts returning the extra bit we added into v2.1 at v2.6
12:26:08 <johnthetubaguy> alex_xu: in v2.6, sure
12:26:27 <johnthetubaguy> alex_xu: that certainly complicates things though...
12:26:44 <johnthetubaguy> gmann: maybe we just leave it out of the v2.0 compat mode for now, and see how we go
12:27:09 <johnthetubaguy> hmm, that feels bad, when I say it like that
12:27:36 <alex_xu> ok, got agremenet, so let's move on ?
12:27:55 <alex_xu> #link https://review.openstack.org/#/c/148509/
12:28:18 <alex_xu> the author want me raise this up, because whether need top-level element, I think it's ok now.
12:28:26 <alex_xu> jaypipes: do you still have concern for that ^
12:28:41 <gmann> ok, so we will add that attribute as version bump
12:28:52 <gmann> and modify v2.1 extension list too?
12:29:23 <gmann> sorry for jumping on previous topic :)
12:29:33 <alex_xu> gmann: yes
12:29:34 <jaypipes> 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 <gmann> cool
12:30:09 <johnthetubaguy> FWIW, local consistency seems worth while
12:30:09 <alex_xu> jaypipes: cool!
12:30:41 <alex_xu> the last one, there is clarify for remove v3 spec
12:30:43 <alex_xu> #link https://review.openstack.org/#/c/193589/
12:31:13 <alex_xu> johnthetubaguy: would you like help on that, it's easy, and the point is raised by you before
12:32:19 <jaypipes> alex_xu: reviewed.
12:32:21 <jaypipes> +1
12:32:30 <johnthetubaguy> cool, that looks good
12:32:30 <alex_xu> jaypipes: thanks :)
12:32:37 <johnthetubaguy> so this subgroup wants that merged right?
12:32:43 <alex_xu> johnthetubaguy: cool, thanks
12:33:01 <alex_xu> johnthetubaguy: this week...only me at here
12:33:24 <alex_xu> johnthetubaguy: I can push other people to give point next week, then I will bother you later~
12:33:25 <johnthetubaguy> so I am thinking of treating this subgroups approval as a +2, and just merging it
12:33:29 <johnthetubaguy> to get people unblocked
12:33:51 <johnthetubaguy> sensible or crazy pants?
12:34:26 * alex_xu can help a +2? ooh~
12:34:48 <johnthetubaguy> anyways, I will add my +2, it looks good
12:35:01 <alex_xu> johnthetubaguy: cool, thanks
12:35:23 <johnthetubaguy> if that not being merged starts blocking people, let me know
12:35:46 <alex_xu> the last last thing...help review microversion client patch https://review.openstack.org/152569 the spec alrready merged!
12:36:04 <alex_xu> johnthetubaguy: ok
12:36:14 <alex_xu> 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 <alex_xu> anymore question? any open? then I will close meeting early~
12:37:02 <johnthetubaguy> thanks folks for all the hard work on the API
12:37:09 <johnthetubaguy> its crazy important for Nova
12:37:16 <alex_xu> :)
12:37:18 <gmann> 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 <alex_xu> gmann: yea ^ also just left few patch
12:37:33 <gmann> few left please review on your free time
12:37:45 <johnthetubaguy> there are all on the etherpad of doom I guess?
12:37:51 <gmann> alex_xu: yea after those just clean up patches i will puch 1 or 2
12:38:02 <alex_xu> gmann: that's worth to put in this etherpad https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
12:38:08 <johnthetubaguy> +1
12:38:11 <gmann> sure
12:38:38 <alex_xu> what is puch...
12:38:53 <gmann> sorry *push :)
12:39:05 <alex_xu> ok...
12:39:10 <gmann> my typo always kills me
12:39:18 <alex_xu> close the meeting 3..
12:39:23 <alex_xu> 2...
12:39:26 <alex_xu> 1...
12:39:34 <alex_xu> #endmeeting