12:02:58 <gilllliard> #startmeeting NovaAPI
12:02:59 <openstack> Meeting started Fri May  1 12:02:58 2015 UTC and is due to finish in 60 minutes.  The chair is gilllliard. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:03:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:03:03 <openstack> The meeting name has been set to 'novaapi'
12:03:09 <gilllliard> Hello everyone :)
12:03:14 <oomichi> gillliard: thanks :)
12:03:14 <johnthetubaguy> o/
12:03:17 <alex_xu> \o/
12:03:20 <oomichi> hi
12:03:27 <eliqiao1> 0/
12:03:32 <gilllliard> Hi eliqiao1 :)
12:03:47 <gilllliard> Thanks for your patience with the time switch.
12:03:52 <eliqiao1> hi gilllliard: glad to join this meeting.
12:04:12 <eliqiao1> thanks alex_xu: for the reminder.
12:04:14 <gilllliard> OK Shall I kick off the agenda stuff?
12:04:18 <alex_xu> eliqiao1: np :)
12:04:29 <gilllliard> #topic Vancouver Summit
12:04:35 <oomichi> yeah, right :) many people are joining to the meeting :)
12:05:05 <gilllliard> We have an API session - alex_xu is leading it IIRC?
12:05:44 <johnthetubaguy> who would like to lead it? we haven't assigned leaders yet as such
12:05:57 <gilllliard> Oh my bad, sorry.
12:06:01 <johnthetubaguy> feel free to step up to lead it on the etherpad though, that would be great :)
12:06:22 <oomichi> #link https://wiki.openstack.org/wiki/Meetings/NovaAPI#Next_Meeting
12:06:30 <alex_xu> I'm non-English speaker, better to have Enlighs speaker leading that. I'd join the discussion
12:06:40 <oomichi> #link https://etherpad.openstack.org/p/liberty-nova-api
12:07:37 <gilllliard> Well I'm happy to do it, although I feel alex_xu and oomichi are more qualified. Perhaps we can share the job?
12:08:06 <alex_xu> gilllliard: yea, thanks, I'm happy sahre the job
12:08:06 <oomichi> we are just collecting topic for the summit, it would be nice to decide who lead them based on the idea.
12:08:22 <oomichi> as the next step.
12:08:32 <gilllliard> oomichi OK that's sensible.
12:08:38 <alex_xu> oomichi: ok
12:08:53 <oomichi> now 3 topics only on the etherpad :(
12:09:08 <alex_xu> actually a lot of thing we want to discussion already at https://etherpad.openstack.org/p/liberty-nova-summit-ideas
12:09:28 <oomichi> #link https://etherpad.openstack.org/p/liberty-nova-summit-ideas
12:09:32 <alex_xu> first I think I guess we need tidy up them, and put in https://etherpad.openstack.org/p/liberty-nova-api
12:10:38 <alex_xu> we probably need put some detail for each discussion, put some existing different standpoint and related reference. it it right oomichi?
12:10:50 <johnthetubaguy> it is good to think about the list of questions you want answered by the end of the session
12:11:16 <johnthetubaguy> there are actually two API sessions currently proposed
12:11:26 <oomichi> alex_xu: yeah, it is great to clarify the detail more.
12:11:35 <johnthetubaguy> it would be great if you take the first one
12:11:43 <gilllliard> johnthetubaguy: do you have a #link for the timetable?
12:11:51 <alex_xu> johnthetubaguy: how we separated those questions into the two sessions, or we will figure that out after we list out all the questions
12:12:07 <johnthetubaguy> gilllliard: the proposed scheduler is at the bottom of the etherpad: https://etherpad.openstack.org/p/liberty-nova-summit-ideas
12:12:40 <johnthetubaguy> its also here: http://libertydesignsummit.sched.org/type/design+summit/Nova
12:12:57 <gilllliard> Thank you. So
12:13:02 <johnthetubaguy> the second API session is more operator focued
12:13:15 <johnthetubaguy> looking at ec2, gce and deprecating v2.0
12:13:30 <johnthetubaguy> I was going to take that one, unless someone really wanted to do it
12:13:51 <johnthetubaguy> the first one we were thinking more about v2.1 next steps
12:14:04 <johnthetubaguy> we can change that, if it doesn't make sese
12:14:06 <johnthetubaguy> sense
12:14:38 <oomichi> johnthetubaguy's nova-spec for relaxing validation is my next step as first prio now
12:15:04 <gilllliard> Yes that's a big one
12:15:09 <oomichi> that would be necessary to remove v2 code soon
12:15:14 <alex_xu> +1
12:15:19 <johnthetubaguy> oomichi: https://review.openstack.org/#/c/173243/
12:15:45 <gilllliard> #action reviews please on https://review.openstack.org/#/c/173243/
12:15:48 <johnthetubaguy> oomichi: soon is likely to be N at this point
12:16:18 <oomichi> johnthetubaguy: yeah,  I hope so :)
12:17:08 <oomichi> johnthetubaguy: strong validation was always concern for v2 comatibility. the spec would help us.
12:17:17 <gilllliard> Anything else for summit?
12:17:45 <alex_xu> +1 for resolve the concern
12:17:54 <oomichi> gillliard: how to bump microversions?
12:18:00 <gilllliard> Well it follows nicely....
12:18:31 <gilllliard> #topic urgent reviews
12:18:43 <gilllliard> alex_xu has some patches up for devrefs
12:19:03 <gilllliard> https://review.openstack.org/#/c/177778/ https://review.openstack.org/#/c/162913/ https://review.openstack.org/#/c/162912/
12:19:18 <eliqiao1> sure, we need the guild to bump version and on what kinds of changes can be allowed in v2.1 api
12:19:25 <gilllliard> I feel these are important as people are trying to use the new API frameworks
12:19:36 <oomichi> gillliard: yeah, these patches will help developers for api development.
12:20:05 <alex_xu> hope can resolve some confuse when reviewing API changes
12:20:18 <alex_xu> special for this one https://review.openstack.org/#/c/177778/
12:20:51 <alex_xu> And there example like this whether we worth to do a change like this https://review.openstack.org/163275
12:21:04 <gilllliard> alex_xu: I pointed a colleague at 177778 today. Will be happy when it lands :)
12:21:40 <oomichi> alex_xu: ok, will try reviewing again later.
12:21:41 <eliqiao1> any changes of api require a version bump ?
12:21:50 <leakypipes> hey guys, sorry I'm late!
12:21:57 <gilllliard> Hello leakypipes :)
12:22:03 <johnthetubaguy> is it working talking about this one: https://review.openstack.org/#/c/163275/
12:22:03 <alex_xu> gilllliard: yes, thanks for your review!
12:22:06 <alex_xu> oomichi: thanks!
12:22:13 <johnthetubaguy> to help guide the review of the API bump policy?
12:22:36 <leakypipes> johnthetubaguy: I actually think it's worthwhile getting the feedback of the API WG on that one.
12:22:36 <johnthetubaguy> so if you lock a locked instance, it just calls that a success right now
12:22:41 <eliqiao1> I wonder some nit changes , still require a version bump?
12:22:56 <leakypipes> eliqiao1: yes.
12:23:02 <johnthetubaguy> leakypipes: yeah, it would be nice to agree a general pattern for that stuff
12:23:07 <leakypipes> eliqiao1: version bumps are cheap now :)
12:23:29 <eliqiao1> leakypipes: sure , thanks.
12:23:38 <johnthetubaguy> leakypipes: +1 if in doubt, its probably worth a bump
12:23:41 <leakypipes> eliqiao1: FWIW, I'm supportive of that patch.
12:23:57 <eliqiao1> leakypipes: thanks for the supporting.
12:23:58 <leakypipes> eliqiao1: I think that the addition of the 409 is worth a version bump on its own.
12:24:06 <gilllliard> So, this https://wiki.openstack.org/wiki/APIChangeGuidelines#Guidelines is from the api-wg, correct?
12:24:06 <alex_xu> leakypipes: but we have example we won't bump for a version just such nit thing https://github.com/openstack/nova/blob/master/nova/api/openstack/api_version_request.py#L42
12:24:10 <leakypipes> eliqiao1: and might as well correct the 202 while doing it.
12:24:12 <leakypipes> IMO
12:24:42 <eliqiao1> leakypipes: cool. glad to fix them.
12:24:42 <leakypipes> alex_xu: ? the version was bumped in 2.2.
12:24:50 <gilllliard> eliqiao1's spec there is item #1 in "Generally not acceptable" on that page, so needs a version bump IMO
12:24:55 <alex_xu> leakypipes: yes
12:25:22 <alex_xu> leakypipes: it is very bother user to upgrade client just for some small thing?
12:25:25 <leakypipes> alex_xu: you are saying that there was a change that *only* changed the return code for create/delete keypair, outside of the original 2.2 patch that added that functionality?
12:26:00 <leakypipes> alex_xu: I don't see much difference between upgrading a client for a small thing or a big thing. it's the same process. same "pain" (minimal)
12:26:18 <leakypipes> but I know dansmith feels differently about that.
12:26:24 <oomichi> on microversions mechanism, we need to bump version even if backwards compatible/incompatible changes.
12:26:56 <oomichi> leakpipes: that is a point of microversions.
12:26:57 <alex_xu> leakypipes: yea, I guess that one point will argument
12:27:18 <leakypipes> alex_xu: with the v3 stuff, everything was "big bang". in other words, we were fixing little things, but upgrading the entire API to a major version. This isn't the case here. We can and should (IMHO) make small fixes and bump the microversion. it's cheap, and nothing breaks older clients ever.
12:27:34 <leakypipes> becasuee they must specifically request the new functionality.
12:27:38 <oomichi> leakpipes: many small api changes to archive better interfaces.
12:27:43 <eliqiao1> I have a concer, if user want feature 1 but it is implmented in 2.100, but he don't want feature 2 which is implemented in 2.99, then, what the version should client use ?
12:28:15 <johnthetubaguy> leakypipes: agreed, the next debate is what changes are worth adding that require clients to update to benefit from them, possibly lots of them
12:28:20 <gilllliard> eliqiao1: if you can do it in 2 calls, then good. There is no version of Nova which satisfies both at once.
12:28:25 <leakypipes> oomichi: right, and contrary to the big v3 thing, the client has the opportunity to gradually and backwards-compatible way align with the latest version without worrying about breakage.
12:28:39 <eliqiao1> gilllliard: understood. thx.
12:28:49 <johnthetubaguy> :S
12:29:07 <leakypipes> johnthetubaguy: I view the microversion bumps as "little API releases". client code should be updated as needed.
12:29:25 <johnthetubaguy> if you want both 2.100 and 2.99 don't you get both features by requesting 2.100
12:29:25 <oomichi> leakypipes: yeah, right.
12:29:28 <leakypipes> johnthetubaguy: we can release a bunch of these microversion "releases" and the client can catch up at any time.
12:29:43 <leakypipes> johnthetubaguy: just like oslo libs. we gradually bring em into nova over time.
12:29:53 <johnthetubaguy> leakypipes: yeah totally agreed, just when you add a feature on top you force them into it, and maybe thats fine
12:30:29 <johnthetubaguy> leakypipes: most clients probably need zero updates for the kinds of fixups we are talking about anyways, so best not to loose too much sleep about it either way really
12:30:30 <alex_xu> compare to v3 that sounds make sense to me...
12:30:40 <leakypipes> johnthetubaguy: well, I don't recommend waiting a *long* time to do the microversion changes of course :) just that it doesn't have to be done immediately or in one giant big bang.
12:30:57 <johnthetubaguy> leakypipes: +1 and thats a big deal
12:31:11 <johnthetubaguy> (in a good way)
12:31:19 <leakypipes> johnthetubaguy: and frankly, this is precisely why we have API and client liaisons.
12:31:24 <oomichi> right, new features are released on the latest microversion. if users want to use, they need to update/catch up the other api changes also.
12:31:27 <leakypipes> to keep track of just this kind of thing.
12:33:05 <gilllliard> Are there any other reviews which people want attention on?
12:33:11 <alex_xu> one more
12:33:22 <johnthetubaguy> so, for the change in questions, do we want 409 for requests to update something thats already been updated (delete a deleting thing, lock a locked thing, etc), thats an API-WG matter
12:33:35 <alex_xu> whether we can correct error status code without microversion like this https://review.openstack.org/#/c/177018/ for now
12:33:44 * johnthetubaguy see Fr Ted for "that would be an ecumenical matter"
12:33:55 <leakypipes> johnthetubaguy: that is what 409 Conflict is for... at least, my reading of the RFC.
12:34:04 * leakypipes checks API WG guidance.
12:35:00 <johnthetubaguy> leakypipes: well, its for you can't "delete" something thats "resizing", thats for sure, "delete" something thats "deleting" seems like a great area
12:35:19 <leakypipes> yay! it's not in the API WG guidance :) that means a perfect opportunity for alex_xu and gilllliard to do the liaison thing :)
12:35:27 <johnthetubaguy> :)
12:35:30 <gilllliard> Depends if you are thinking of it as performing an action, or asserting a result :)
12:35:40 <oomichi> hehe
12:35:51 <leakypipes> gilllliard, alex_xu: feel like making a proposal to add 409 conflict to here? http://git.openstack.org/cgit/openstack/api-wg/tree/guidelines/http.rst
12:36:07 <gilllliard> #action (gilliard, alex_xu) - clarify with API-WG the response to a request to move a resource into a state which it is already in.
12:36:13 <eliqiao1> HEHE...
12:36:14 <alex_xu> leakypipes: got it
12:36:26 <leakypipes> ty guys :)
12:36:29 * alex_xu API-WG guilding looks like missing a lot
12:36:39 * gilllliard rolls up sleeves
12:36:45 <leakypipes> alex_xu: it's a "living document"
12:36:54 <leakypipes> alex_xu: that's a nice way of agreeing with you ;)
12:37:05 <alex_xu> leakypipes: yea
12:37:13 <eliqiao1> alex_xu: we need add api-wg guild to our api-microversion rst.
12:37:34 <leakypipes> alex_xu: that said, the original idea of the API WG was to create guidelines based on proposals from the projects themselves and work collaboratively with each other. this is a great opportuntity to do so.
12:37:35 <oomichi> eliqiao1: +1
12:38:02 <leakypipes> well, first steps first. I think a clarification on 409 Conflict should be done first.
12:38:03 <alex_xu> leakypipes: ok, got it
12:38:07 <alex_xu> eliqiao1: +1
12:38:33 <gilllliard> alex_xu: you raised another review just now?
12:38:36 <eliqiao1> leakypipes: +1
12:39:03 <alex_xu> yea, this one https://review.openstack.org/#/c/177018/ , some exception we didn't catch, it lead to return 500.
12:39:37 <alex_xu> before we can fix it directly, but now we said any api change need microversion..so what we should do for now?
12:40:00 * leakypipes reads
12:40:04 <alex_xu> currently version of https://review.openstack.org/#/c/177018/ say it need bump the microversion, but hope get some agreement
12:40:26 <johnthetubaguy> alex_xu: I don't think that needs a microversion bump, 500->anything feels like a reasonable change without a spec
12:40:47 <eliqiao1> johnthetubaguy: +1, user will not notice this change.
12:40:52 <oomichi> alex_xu: that was an internal error and a just bug. I think microversion bump is not necessary
12:40:57 <gilllliard> esp as this is a regression since v2
12:41:17 <leakypipes> johnthetubaguy: I would agree with that. reasoning: 500 is not a correct response *ever* for a user-space error like this. Therefore we aren't "changing" the API, but rather fixing a bug.
12:41:45 <oomichi> leakypipes: +1
12:42:04 <alex_xu> ok, cool, that make sense to me
12:42:09 <leakypipes> if for some strange reason, we had considered 500 to be an acceptable error returned to the user in this case, then I would argue that yes a microversion bump was needed. but that's not the case here.
12:42:19 <gilllliard> That is a worthwhile point. alex_xu you could refer to it from your devref?
12:42:42 <johnthetubaguy> leakypipes: lets add 500 as a unacceptable return value for an expected error I guess?
12:42:45 <alex_xu> gilllliard: ok
12:43:00 * leakypipes considers any error returned to the user as a 500 to be leaking of implementation details out of the API (and that's A Bad Thing, m'kay!)
12:43:21 <johnthetubaguy> leakypipes: +1 but we may as well add it to the API-WG doc
12:43:35 <leakypipes> johnthetubaguy: ++ agreed.
12:43:46 <leakypipes> #action jaypipes to submit guidance on 500 not being acceptable.
12:43:55 <johnthetubaguy> awesome, thanks
12:44:02 <alex_xu> leakypipes: thanks
12:44:27 <gilllliard> Any more reviews?
12:44:28 <eliqiao1> alxe_xu: need to fix it also in https://review.openstack.org/#/c/177778/6/doc/source/devref/api_microversions.rst line 212
12:44:49 <eliqiao1> for 500 -> other code...
12:44:50 <alex_xu> eliqiao1: yea, I will update it along with the example
12:44:58 <eliqiao1> coll.
12:45:02 <eliqiao1> cool
12:45:03 <johnthetubaguy> gilllliard: is it work talking about my spec here?
12:45:32 <gilllliard> yeah sure. Conscious of time though.
12:45:37 <johnthetubaguy> https://review.openstack.org/173243
12:45:59 <johnthetubaguy> so this is the relax API validation for v2.0 requests made to the v2.1 API
12:46:14 <johnthetubaguy> the idea being, get more folks using the v2.1 code sooner
12:46:45 <johnthetubaguy> my basic propose is change the meaning of a request without a version header
12:46:54 <johnthetubaguy> the original spec said assume it means the min_version
12:47:08 <johnthetubaguy> I am basically saying assume it means its a v2.0 request
12:47:36 <johnthetubaguy> now thats basically the same thing right now, but relaxing the validation changes that, as v2.1 requests would get strong validation
12:48:00 <johnthetubaguy> alex_xu: you made some good comments on the spec, I think you had some concerns with the idea?
12:48:28 <leakypipes> tada: https://review.openstack.org/179365
12:48:41 <alex_xu> johnthetubaguy: yea, that means we lose the chance to raise the min_version, this point I'm not sure
12:48:44 <leakypipes> the 4 minute guidance. ;)
12:48:58 <alex_xu> although I know there won't raise the min_version in short term
12:49:25 <johnthetubaguy> not really
12:49:33 <johnthetubaguy> I suggest adding a new header for that
12:49:43 <johnthetubaguy> you could add a header that says "min_version"
12:49:46 <johnthetubaguy> rather than "latest"
12:49:52 <johnthetubaguy> but I don't think anyone would use that
12:50:23 <johnthetubaguy> it does mean we could raise the min_version without dropping v2.0 support, but thats probably a dumb idea
12:50:51 <alex_xu> it means the relax validation v2 api will keep forever
12:51:13 <johnthetubaguy> yes
12:51:31 <johnthetubaguy> but, we expect clients to start requests microversions soon
12:51:38 <johnthetubaguy> and all those requests will get strong validation
12:51:42 <alex_xu> if we raise min_version to drop the relax validation, that give our chance to force all the client/SDK fix their problem.
12:51:53 <oomichi> if we will be able to provide great new features in the future, many users will use newer versions
12:52:51 <oomichi> but I'm not sure that now, and I can see  alex_xu's point
12:53:08 <alex_xu> raise min_version is used for us drop some burden in the future. I guess there maybe have 2.30 or 2.50, there will be a lot of multiversion function in the api code
12:53:15 <johnthetubaguy> so, if we drop the relax of the validation
12:53:19 <johnthetubaguy> we drop support for the v2.0 aPI
12:53:44 <johnthetubaguy> now thats a thing we might consider in a few years, but I tie the two together in my head
12:53:59 <alex_xu> johnthetubaguy: maybe drop that after three or four release, will that safe?
12:54:03 <johnthetubaguy> I don't see us ever raising the min_version, for the same reason we can't drop v2.0 support, at least not for a good few years
12:54:12 <johnthetubaguy> alex_xu: it would be much longer I suspect
12:54:42 <johnthetubaguy> alex_xu: the public clouds would want to confirm they have no API requests missing the version header before wanting to drop that v2.0 support
12:54:48 <johnthetubaguy> alex_xu: same for raising the min_version
12:54:54 <eliqiao1> then, we back again to support 2 version api ...(just like before , v2 and v3)
12:55:00 <johnthetubaguy> alex_xu: people just write hacky scripts, and we don't want to break them
12:55:32 <eliqiao1> johnthetubaguy: I think we need to here more vice from operators.. for the supporting v2 api
12:56:10 <alex_xu> johnthetubaguy: but people have motivation upgrade their code, when they want to use new feature by microversion :)
12:56:38 <johnthetubaguy> eliqiao1: I am speaking on behalf of rackspace public cloud here, with my operator hat on, but I would love to hear what other folks thing
12:56:53 <oomichi> alex_xu: yeah, and they will find their own bugs in client code
12:57:11 <johnthetubaguy> right, as the SDKs use new features
12:57:24 <johnthetubaguy> they will use the new validation, and I think, all is good
12:57:44 <gilllliard> johnthetubaguy: does your spec inclue any way to measure how many microversionless requests are being served?
12:57:48 <oomichi> now SDKs are 30+, so it would be difficult to track all of them
12:58:02 <gilllliard> That might be useful to gauge the extent of the potential annoyance.
12:58:03 <johnthetubaguy> eliqiao1: my worry with v3 was having two parallel code bases, v2.1 and microverions is designed to avoid that, and we are very close to that working here
12:58:26 <johnthetubaguy> gilllliard: I don't pull that out here, I would hope that appears in the API logs already, if not we can add that for sure
12:58:45 <gilllliard> So we're almost out of time...
12:59:23 <gilllliard> in fact, we really are out of time.
12:59:31 <alex_xu> johnthetubaguy: maybe we need discuss that at summit
12:59:46 <johnthetubaguy> alex_xu: that the plan for the second API session
12:59:47 <gilllliard> #action alex_xu add this spec to the summit agenda
12:59:52 <johnthetubaguy> alex_xu: discuss it with the operators
12:59:56 <gilllliard> oh good :)
13:00:03 <alex_xu> johnthetubaguy: +1
13:00:16 <eliqiao1> yeah, a face to face discussion will be better, besides, need to hear clints' suggestion :)
13:00:53 <gilllliard> Thanks everyone
13:00:59 <oomichi> thanks all
13:01:05 <alex_xu> thanks all
13:01:13 <gilllliard> #endmeeting