00:01:40 <cyeoh> #startmeeting nova api
00:01:41 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:45 <openstack> The meeting name has been set to 'nova_api'
00:01:57 <cyeoh> Hi - who's here today?
00:02:00 <alex_xu> hi
00:02:08 <oomichi> hi
00:02:58 <cyeoh> ok. lets get started.
00:03:10 <cyeoh> #topic v2.1 on v3
00:03:29 <cyeoh> https://etherpad.openstack.org/p/nova-juno-spec-priorities
00:03:58 <cyeoh> 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 <cyeoh> please review https://review.openstack.org/#/c/84695/ if you can
00:04:57 <cyeoh> 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 <oomichi> +1 for current spec of v2.1 :-)
00:05:37 <alex_xu> I will take a look today, I think it 'sgood for me
00:05:46 <cyeoh> thx - I will update it with any feedback today and Monday
00:05:51 <gmann> cyeoh: now it include the microversion part also right?
00:06:04 <cyeoh> gmann: yes, it has incorporated Sean's microversion proposal
00:06:10 <cyeoh> since we were dependent on it anyway
00:06:44 <cyeoh> 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 <cyeoh> (I hope I'll be back soon, but I might not be)
00:07:14 <oomichi> interesting point is that each backwards incompatible change increase version "X". now I agree with that.
00:07:23 <cyeoh> oomichi: would you mind handling updating the spec if it needs it while I'm away?
00:07:44 <oomichi> cyeoh: ok, i can do it ;-)
00:08:08 <cyeoh> oomichi: thx!
00:08:31 <oomichi> cyeoh: np, I will check status this week end always.
00:08:53 <cyeoh> 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 <oomichi> cyeoh: the idea seems great for me now, that should be microversion.
00:09:53 <cyeoh> 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 <oomichi> cyeoh: when we find something wrong in the future, we can fix it. that is nice for us.
00:10:46 <cyeoh> oomichi: yep we no longer stuck with horrible apis forever
00:10:55 <oomichi> cyeoh: we can continue improving our interfaces.
00:11:08 <cyeoh> is there anything else that people wanted to talk about microversions of v2.1 on v3?
00:11:24 <oomichi> cyeoh: agree, great spec:-)
00:11:30 <gmann> 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 <cyeoh> gmann: yess
00:12:04 <cyeoh> but if they don't want the new stuff, they can just request the old one as usual
00:12:38 <cyeoh> its not like say a v2->v3 transition where people would have been forced to use the new api
00:12:46 <gmann> 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 <cyeoh> gmann: we need to support continuous deployment for starters
00:13:51 <cyeoh> 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 <cyeoh> the other thing it allows is for say a user to say after a release that they just want x=4
00:14:19 <oomichi> 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 <cyeoh> and not have the new feature offered in x=5.
00:14:50 <cyeoh> 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 <cyeoh> 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 <gmann> cyeoh: ohk, so you mean we will support for each in-between X version also after release too
00:16:39 <cyeoh> gmann: yes
00:16:58 <gmann> ok, got it Thanks.
00:17:02 <cyeoh> gmann: its one reason maintenance for all this code has to be really low
00:17:23 <cyeoh> 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 <cyeoh> #topic api specs reviews
00:17:52 <gmann> yes.
00:18:27 <cyeoh> 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 <cyeoh> 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 <cyeoh> 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 <cyeoh> (an example of this is say adding the ability to show which instances are locked
00:20:05 <cyeoh> because we don't want these sorts of changes held up for a cycle
00:20:28 <cyeoh> oomichi: if this is something you think is reasonable, perhaps you could bring it up at the mid-cycle meetup?
00:20:42 <oomichi> re: lock: yes, that is really trivial.
00:20:57 <oomichi> cyeoh: yes, I will join mid-cycle.
00:21:19 <oomichi> cyeoh: and I will bring them on the meetup.
00:21:34 <cyeoh> 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 <cyeoh> hopefully that would speedup approval and we still have a second chance to pick up issues during normal code review
00:22:09 <oomichi> cyeoh: np, will check them again before the meetup
00:22:20 <cyeoh> cool :-)
00:23:09 <cyeoh> #topic Open Discussion
00:23:09 <oomichi> cyeoh: do you have anything special in the specs except v2.1?
00:23:27 <cyeoh> oomichi, well I don't think anything else is going to get approved :-(
00:23:39 <cyeoh> I think a couple of alex_xu's would be really nice to be able to work on - re: api policy
00:23:53 <cyeoh> but if v2.1 on v3 gets approved we will be totally flat out
00:24:08 <oomichi> cyeoh: ah, I agree. api policy is already nice/important.
00:24:12 <alex_xu> yes
00:24:28 <cyeoh> if you can get them approved at the midcycle it would be great :-)
00:24:41 <cyeoh> but of course v2.1 on v3 has the priority....
00:24:54 <alex_xu> agreed
00:24:56 <oomichi> yep, right.
00:25:17 <alex_xu> oomichi, thx
00:25:22 <oomichi> there are some approved specs based on v3 api.
00:26:05 <oomichi> if not getting approval for v2.1, they also are not exposed..
00:26:45 <alex_xu> 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 <cyeoh> alex_xu: so if its a bug fix you might be able to just merge it
00:27:50 <alex_xu> cyeoh, you mean I can update them now?
00:28:03 <cyeoh> if its just a bug fix rather than new feature, I'd give it a go
00:28:19 <alex_xu> cyeoh, and those bug fix still reference to old bp v3-api-inconsistencies
00:28:29 <alex_xu> for example, https://review.openstack.org/#/c/58458/
00:29:08 <oomichi> alex_xu: better to skip them after the approval. because we will have a lot of v2.1 tasks.
00:29:11 <cyeoh> so those sorts of ones that make 'v3' changes, I don't think we'll be able to merge yet
00:29:31 <oomichi> alex_xu: we can fix them as microversion.
00:29:52 <alex_xu> ok, let me skip them
00:29:56 <cyeoh> 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 <alex_xu> ok
00:30:11 <cyeoh> yep I agree with what oomichi said
00:30:31 <oomichi> cyeoh: agree to fix bad error response codes.
00:30:50 <cyeoh> yep
00:31:06 <oomichi> ah, one point.
00:31:42 <oomichi> can we add tenant-id to the url of v3 API?
00:32:08 <alex_xu> good point~
00:32:20 <cyeoh> we don't want the tenant-id do we?
00:32:29 <cyeoh> (or do you mean for v2.1 compat?)
00:32:41 <oomichi> if we never expose v3 api forever, that is the big difference between v2 and v3
00:33:02 <oomichi> yes, v2.1 compat
00:33:02 <cyeoh> so we'll eventually do a microversion bump where we remove it
00:33:23 <oomichi> ah, interesting idea.
00:33:26 <cyeoh> as its not only not actually used, but its confusing because its not used
00:33:40 <cyeoh> I'd like to actually do a microversion bump where we remove '/v2'
00:33:54 <cyeoh> it doesn't make any sense in a microversion environment either
00:34:05 <oomichi> ok, now let keep tenant-id in the url.
00:34:21 <alex_xu> the new api  shoule use 'tenant_id' or 'project_id' before v3 exposed by micro-version?
00:35:03 <cyeoh> 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 <cyeoh> but it doesn't actually use it (even v2 gets the project id info from the context now)
00:36:32 <cyeoh> 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 <cyeoh> 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 <eliqiao> cyeoh: a question , if user use v2.1 api, will /v2.1 appear in the request url ?
00:38:09 <cyeoh> 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 <cyeoh> eliqiao: so initially by default I think we will export as /v2.1
00:38:39 <eliqiao> cyeoh: thx
00:38:45 <cyeoh> eliqiao: this allows deployers to deploy both /v2 and /v2.1
00:39:02 <cyeoh> however its just a minor change to api-paste.ini and v2.1 can be exported as /v2
00:39:11 <cyeoh> there's nothing hardcoded to /v2.1 at all
00:40:07 <oomichi> right, we can use v2.1 as v2 default also.
00:40:18 <cyeoh> yep
00:41:06 <cyeoh> is there anything else that people wanted to talk about? I'm out of stuff
00:41:32 <eliqiao> if I understand correctlly , just add
00:41:33 <eliqiao> /: oscomputeversions
00:41:33 <eliqiao> /v1.1: openstack_compute_api_v2
00:41:33 <eliqiao> /v2: openstack_compute_api_v2
00:41:33 <eliqiao> /v3: openstack_compute_api_v3
00:41:33 <eliqiao> /v2.1: openstack_compute_api_v2
00:41:33 <eliqiao> is that correct ?
00:41:50 <cyeoh> eliqiao: yea, that's basically how you can configure it
00:42:24 <eliqiao> cyeoh: :） thank you.
00:44:14 <cyeoh> does anyone have anything else? otherwise I'll end the meeting early
00:44:28 <oomichi> nice meeting, nothing from me.
00:44:49 <gmann> me too
00:44:55 <cyeoh> ok, thanks everyone
00:44:58 <cyeoh> #endmeeting