00:01:40 #startmeeting nova api 00:01:41 Meeting started Fri Jul 18 00:01:40 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:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:01:45 The meeting name has been set to 'nova_api' 00:01:57 Hi - who's here today? 00:02:00 hi 00:02:08 hi 00:02:58 ok. lets get started. 00:03:10 #topic v2.1 on v3 00:03:29 https://etherpad.openstack.org/p/nova-juno-spec-priorities 00:03:58 so at the nova meeting today we got an exception for the v2.1 on v3, BUT its not approved. We have I think a week to get it approved 00:04:33 please review https://review.openstack.org/#/c/84695/ if you can 00:04:57 if it looks good to you, +1 it as it will show the nova drivers reviewers that it has the support of the api team 00:05:09 +1 for current spec of v2.1 :-) 00:05:37 I will take a look today, I think it 'sgood for me 00:05:46 thx - I will update it with any feedback today and Monday 00:05:51 cyeoh: now it include the microversion part also right? 00:06:04 gmann: yes, it has incorporated Sean's microversion proposal 00:06:10 since we were dependent on it anyway 00:06:44 now next Tuesday I will be going in for same day surgery so its unclear if I'll be able to update the spec wed/thu/fri 00:06:53 (I hope I'll be back soon, but I might not be) 00:07:14 interesting point is that each backwards incompatible change increase version "X". now I agree with that. 00:07:23 oomichi: would you mind handling updating the spec if it needs it while I'm away? 00:07:44 cyeoh: ok, i can do it ;-) 00:08:08 oomichi: thx! 00:08:31 cyeoh: np, I will check status this week end always. 00:08:53 oomichi: and re:X yes I think we need to get people used to the idea that with microversions small numbers of small backwards incompatible changes and if X gets bumped a lot that is fine 00:09:37 cyeoh: the idea seems great for me now, that should be microversion. 00:09:53 oomichi: yep, if I'm not back by the nova meeting on Friday you might need to bring it up there to make sure it gets reconsidered - I'm hoping it will be approved by then though 00:10:30 cyeoh: when we find something wrong in the future, we can fix it. that is nice for us. 00:10:46 oomichi: yep we no longer stuck with horrible apis forever 00:10:55 cyeoh: we can continue improving our interfaces. 00:11:08 is there anything else that people wanted to talk about microversions of v2.1 on v3? 00:11:24 cyeoh: agree, great spec:-) 00:11:30 1 question. as each backward incompatible leads to bump X. At the end of release user will see the version bump from x1 to x5 (if that many backward incompatible changes done within release) 00:11:48 gmann: yess 00:12:04 but if they don't want the new stuff, they can just request the old one as usual 00:12:38 its not like say a v2->v3 transition where people would have been forced to use the new api 00:12:46 so from user point of view in between version bump is not visible. so what is the main advantage of bumping X for each backward incompatible changes instead of just bump once at the end of release 00:13:27 gmann: we need to support continuous deployment for starters 00:13:51 so as stuff merges during the cycle those operators who deploy straight away can allow their users to start using the new apis 00:14:11 the other thing it allows is for say a user to say after a release that they just want x=4 00:14:19 I think the good point that we don't need to consider the end of release. and CD environments, we can use the latest APIs as experimental. 00:14:21 and not have the new feature offered in x=5. 00:14:50 as they may not want the feature or the work required to handle the backwards incompatible change involved in transitioning from x=4 -> x=5 yet 00:15:53 oomichi: yep we shouldn't be doing any synchornising of what x is at the end of a cycle, its just a number. 00:16:27 cyeoh: ohk, so you mean we will support for each in-between X version also after release too 00:16:39 gmann: yes 00:16:58 ok, got it Thanks. 00:17:02 gmann: its one reason maintenance for all this code has to be really low 00:17:23 and if the backwards incompatible changes are small each time it'll also make it easier to understand/maintain in the future 00:17:44 #topic api specs reviews 00:17:52 yes. 00:18:27 so one thing we changed in icehouse was requiring *any* api change, even if pretty trivial to go through nova-specs to make sure we don't acidentally make a backwards incompatible change 00:18:51 unfortunately from what I can see there are lots and lots of quite trivial api specs which are stuck in the nova-specs queue 00:19:22 I've been thinking we should ask the nova-drivers folks if there can be a fast track for the trivial nova api spec changes 00:19:41 (an example of this is say adding the ability to show which instances are locked 00:20:05 because we don't want these sorts of changes held up for a cycle 00:20:28 oomichi: if this is something you think is reasonable, perhaps you could bring it up at the mid-cycle meetup? 00:20:42 re: lock: yes, that is really trivial. 00:20:57 cyeoh: yes, I will join mid-cycle. 00:21:19 cyeoh: and I will bring them on the meetup. 00:21:34 thx - I was thinking something like, say a only requiring say a nova-core who is familiar with the api (say you or me) and just one nova-driver, rather than 2 00:22:00 hopefully that would speedup approval and we still have a second chance to pick up issues during normal code review 00:22:09 cyeoh: np, will check them again before the meetup 00:22:20 cool :-) 00:23:09 #topic Open Discussion 00:23:09 cyeoh: do you have anything special in the specs except v2.1? 00:23:27 oomichi, well I don't think anything else is going to get approved :-( 00:23:39 I think a couple of alex_xu's would be really nice to be able to work on - re: api policy 00:23:53 but if v2.1 on v3 gets approved we will be totally flat out 00:24:08 cyeoh: ah, I agree. api policy is already nice/important. 00:24:12 yes 00:24:28 if you can get them approved at the midcycle it would be great :-) 00:24:41 but of course v2.1 on v3 has the priority.... 00:24:54 agreed 00:24:56 yep, right. 00:25:17 oomichi, thx 00:25:22 there are some approved specs based on v3 api. 00:26:05 if not getting approval for v2.1, they also are not exposed.. 00:26:45 I have a set of bug fix for v3 api, So waiting for v2.1 get approved, then I can continue them? 00:27:24 alex_xu: so if its a bug fix you might be able to just merge it 00:27:50 cyeoh, you mean I can update them now? 00:28:03 if its just a bug fix rather than new feature, I'd give it a go 00:28:19 cyeoh, and those bug fix still reference to old bp v3-api-inconsistencies 00:28:29 for example, https://review.openstack.org/#/c/58458/ 00:29:08 alex_xu: better to skip them after the approval. because we will have a lot of v2.1 tasks. 00:29:11 so those sorts of ones that make 'v3' changes, I don't think we'll be able to merge yet 00:29:31 alex_xu: we can fix them as microversion. 00:29:52 ok, let me skip them 00:29:56 but if there's a patch that say fixes a bug in the v3 api where it doesn't work properly (say returns a 500), then yes they can merge 00:30:07 ok 00:30:11 yep I agree with what oomichi said 00:30:31 cyeoh: agree to fix bad error response codes. 00:30:50 yep 00:31:06 ah, one point. 00:31:42 can we add tenant-id to the url of v3 API? 00:32:08 good point~ 00:32:20 we don't want the tenant-id do we? 00:32:29 (or do you mean for v2.1 compat?) 00:32:41 if we never expose v3 api forever, that is the big difference between v2 and v3 00:33:02 yes, v2.1 compat 00:33:02 so we'll eventually do a microversion bump where we remove it 00:33:23 ah, interesting idea. 00:33:26 as its not only not actually used, but its confusing because its not used 00:33:40 I'd like to actually do a microversion bump where we remove '/v2' 00:33:54 it doesn't make any sense in a microversion environment either 00:34:05 ok, now let keep tenant-id in the url. 00:34:21 the new api shoule use 'tenant_id' or 'project_id' before v3 exposed by micro-version? 00:35:03 so I have a patch somewhere that allows the tenant id to be passed in the url when in v2.1 compat mode 00:35:30 but it doesn't actually use it (even v2 gets the project id info from the context now) 00:36:32 what we do probably need to think about a bit (assuming v2.1 on v3 gets approved soon) is how make the v2.1/v3 switching logic a bit more generic 00:37:24 at the moment when a request comes in we either do v2.1 or v3. But longer term we'll need to think about in terms of say an opaque "microversions object" 00:38:08 cyeoh: a question , if user use v2.1 api, will /v2.1 appear in the request url ? 00:38:09 this object has the version information contained in it. And our infrastructure switches through the different decorators based on how the microversions object matches against the version defs in the decorators 00:38:29 eliqiao: so initially by default I think we will export as /v2.1 00:38:39 cyeoh: thx 00:38:45 eliqiao: this allows deployers to deploy both /v2 and /v2.1 00:39:02 however its just a minor change to api-paste.ini and v2.1 can be exported as /v2 00:39:11 there's nothing hardcoded to /v2.1 at all 00:40:07 right, we can use v2.1 as v2 default also. 00:40:18 yep 00:41:06 is there anything else that people wanted to talk about? I'm out of stuff 00:41:32 if I understand correctlly , just add 00:41:33 /: oscomputeversions 00:41:33 /v1.1: openstack_compute_api_v2 00:41:33 /v2: openstack_compute_api_v2 00:41:33 /v3: openstack_compute_api_v3 00:41:33 /v2.1: openstack_compute_api_v2 00:41:33 is that correct ? 00:41:50 eliqiao: yea, that's basically how you can configure it 00:42:24 cyeoh: :） thank you. 00:44:14 does anyone have anything else? otherwise I'll end the meeting early 00:44:28 nice meeting, nothing from me. 00:44:49 me too 00:44:55 ok, thanks everyone 00:44:58 #endmeeting