00:00:44 <cyeoh> #startmeeting nova-api
00:00:45 <openstack> Meeting started Fri May 30 00:00:44 2014 UTC and is due to finish in 60 minutes.  The chair is cyeoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:00:49 <openstack> The meeting name has been set to 'nova_api'
00:01:00 <cyeoh> Hi - who's here today?
00:01:04 <soulxu1404> hi
00:01:08 <oomichi> hello
00:01:10 <alex_xu> hi
00:01:10 <tian> hi
00:01:43 <cyeoh> cool - let's get started
00:01:50 <cyeoh> #topic v2.1 on v3
00:02:07 <cyeoh> so the nova spec proposal for this is here:
00:02:12 <cyeoh> #link https://review.openstack.org/#/c/84695/
00:02:49 <cyeoh> please review and comment if you have the time. I will update based on feedback. Obviously we want to get this approved asap so we can start merging all the code we have
00:03:23 <cyeoh> is there anything that anyone wants to talk about the spec for this on v2.1 on v3 generally now?
00:04:01 <oomichi> that is enough for me by talking it on nova-specs.
00:04:28 <oomichi> nothing from me now.
00:05:01 <cyeoh> ok. so my suggestion is we progress as much as we can on it for the next week and if its not approved by then we bring it to next week's main nova meeting
00:05:28 <oomichi> cyeoh: cool, that would be nice:)
00:05:29 <cyeoh> to hopefully get it approved
00:05:41 <alex_xu> cyeoh, cool
00:05:53 <cyeoh> #action cyeoh to bring v2 on v3 nova-spec proposal to next nova meeting if not approved by then
00:05:54 <oomichi> ceyoh: agree, we need to approve it soon.
00:06:20 <cyeoh> #topic microversions API
00:06:28 <cyeoh> #link https://wiki.openstack.org/wiki/Nova/ProposalForAPIMicroVersions
00:06:41 <cyeoh> #link https://review.openstack.org/#/c/96139/
00:07:05 <cyeoh> the difficulty with the microversions is that we have two quite distinct views on what microversions is
00:07:29 <cyeoh> so although from what I understand there was consensus on going the microversions route its not clear which one people meant
00:08:17 <oomichi> cyeoh: yep, we need to discuss it more.
00:08:26 <oomichi> cyeoh: one question.
00:08:31 <cyeoh> I think the first (separate versioning on each extension) is reasonably fleshed out, but the later needs a bit more research/work
00:08:37 <cyeoh> oomichi: sure, go ahead
00:08:47 <oomichi> cyeoh; thanks
00:08:49 <oomichi> cyeoh: when you add version of each API extension to v3 API, would you increase their version when adding some API parameters to exisiting API?
00:09:00 <oomichi> s/add/added/
00:09:22 <cyeoh> yes
00:09:41 <oomichi> cyeoh: thanks, the same idea:)
00:09:49 <cyeoh> any change incompatible or not would be a version bump
00:10:11 <cyeoh> yep, that removes the need to add "dummy" extensions
00:10:28 <oomichi> OK, I got it. I will discuss it on the direction.
00:10:55 <cyeoh> so I need to a bit more research/reading on the second proposal and will do a bit of an update, but everyone should definitely feel very welcome to update the spec and/or add comments
00:11:04 <cyeoh> as we need to get this nailed down pretty quickly too
00:11:28 <oomichi> cyeoh: yep.
00:11:34 <cyeoh> and I'd like to exclude one of them fairly soon (say in the next week) so we can just concentrate on getting one right
00:11:58 <cyeoh> anything even like a pro/cons list section for each would be helpful I think
00:12:18 <oomichi> cyeoh: agree, I also will write it on gerrit.
00:12:32 <cyeoh> oomichi: thx!
00:12:38 <tian> should we also need the V3 novaclient  when use the micoversions?
00:12:57 <cyeoh> tian: hrm, so that's an interesting question.
00:13:13 <cyeoh> it gets a bit trickier for novaclient - it will be more of a v2-microversions aware novaclient
00:13:44 <cyeoh> perhaps novaclient-microversions will always track the latest stable microversion?
00:14:00 <tian> cyeoh: that's say, we will have one novaclient ?
00:14:40 <cyeoh> tian: my guess would be one novaclient codebase, but there will probably be a need to a novaclient interface which supports vanilla v2
00:14:53 <tian> cyeoh : got it , cool
00:14:55 <cyeoh> and one which support v2-microversions (don't know how many stable microversions it will support)
00:15:15 <cyeoh> part of the issue is how much novaclient insulates the caller from API which didn't really get discussed at summit unfortunately
00:15:23 <cyeoh> for the command line its easy - the user doesn't really care
00:15:33 <cyeoh> but if its being used as an SDK, then parameter name changes etc do matter.
00:16:12 <cyeoh> anything else on microversions before we move on?
00:16:32 <tian> none for me
00:16:40 <cyeoh> #topic tasks api
00:17:00 <cyeoh> #link https://review.openstack.org/#/c/86938/
00:17:31 <cyeoh> alaski has is tasks api nova-spec proposal there. It's pretty mature and worth a read
00:17:56 <cyeoh> just a heads up, but I imagine it'll be the first big thing that uses microversions
00:18:24 <oomichi> agree to use microversions. that is interesting feature:-)
00:18:56 <cyeoh> yep it will make for a much nicer interface for users
00:19:10 <cyeoh> #topic tempst api response validation work
00:19:21 <cyeoh> oomichi: just put that in here in case you wanted to take about it
00:19:43 <oomichi> cyeoh: we have already implemented most patches for it.
00:20:02 <oomichi> and just waiting for reviews. so nice progress now.
00:20:09 <cyeoh> oomichi: cool :-)
00:20:25 <oomichi> cyeoh: thanks:)
00:20:41 <oomichi> so now nothing to need to discuss it:)
00:20:50 <cyeoh> ok :)
00:21:02 <cyeoh> #topic sdk port
00:21:29 <cyeoh> not sure if mrda is around, but given microversions, the context of this has probably changed to how hard it is to wedge client accept headers into an SDK
00:21:39 <cyeoh> anyway discussion on this can probably wait
00:22:03 <cyeoh> for input validation checks, that's still on my todo list
00:22:32 <cyeoh> oomichi: anything you wanted to talk about API extensions? I think your patch is in the review queue IIRC?
00:22:42 <oomichi> cyeoh: re: nova input validation
00:22:54 <oomichi> now nova-specs about it is reviewed.
00:23:14 <oomichi> #link https://review.openstack.org/#/c/85640/
00:23:30 <oomichi> I hope it will be approved soon.
00:23:49 <oomichi> and the patches have already implemented. so just waiting for reviews;)
00:23:57 <cyeoh> ah ok, have you tried pinging mikal to remove the -2?
00:24:20 <oomichi> yep, and waiting for him. I will ping him again later.
00:24:47 <cyeoh> ok, cool. I'll review it today, though I don't have +2 powers on nova-specs ;-)
00:25:20 <oomichi> cyeoh: but your +1 is really important for nova api spec:)
00:25:36 <cyeoh> heh
00:25:41 <oomichi> thanks in advance;-)
00:26:04 <cyeoh> was there anything else from anyone before we move on?
00:26:21 <oomichi> that is all from me
00:26:38 <cyeoh> #topic correct error code for over quota errors
00:27:03 <cyeoh> so this has come up a bit lately - for overquota 413 is definitely wrong, but there's a bit of a dispute over whether it should be 403 or 400
00:27:21 <cyeoh> I'm not sure if there was a debate about this while I was off sick, but I can't find it.
00:27:27 <cyeoh> on the mailing list anyway
00:27:49 <cyeoh> does anyone remember if there was any sort of consensus found for this at summit or elsewhere?
00:28:28 <oomichi> sorry, nothing from me:-(
00:29:01 <cyeoh> ok I'll bring it up on the mailing list. A quick google seems to show that for REST APIs generally 403 is pretty popular under these circumstances
00:29:15 <cyeoh> I don't think its a big thing, but we should be consistent across the openstack APIs
00:29:16 <oomichi> http403 seems better, but some patch which is in gerrit now changes http400.
00:29:46 <dims> Hi cyeoh!!!!!
00:29:53 <cyeoh> yep I a gree I think 403 is better. I just didn't want to re-open a debate on something we might already have consensus on :-)
00:29:58 <cyeoh> dims: hi :-)
00:30:08 <dims> cyeoh, very happy to see you :)
00:30:17 <cyeoh> dims: good to be back :-)
00:30:45 <cyeoh> #action cyeoh to send a mail to openstack-dev about 400 vs 403 for over quota errors
00:31:09 <oomichi> https://review.openstack.org/#/c/95671/ is related to this topic.
00:31:45 <cyeoh> oomichi: yep I'd rather we didn't churn between 400 and 403 :-)
00:32:09 <cyeoh> #topic open discussion
00:32:33 <cyeoh> so anything that anyone wants to talk about?
00:32:51 <alex_xu> I have question for nova api policy
00:33:10 <cyeoh> alex_xu: sure, go ahead!
00:33:19 <alex_xu> I have think of whether we should enable those policy improvement for v2 api
00:33:28 <alex_xu> I added comment at nova specs #link https://review.openstack.org/92005
00:33:45 <alex_xu> I want to hear you guys suggestion
00:35:40 <cyeoh> alex_xu: so whilst the first option of just have an upgrade impact flag would be easier for a developer point of view
00:36:01 <cyeoh> if we were to go that way I think it really needs input from the CD people that this would be ok
00:36:12 <cyeoh> eg Phil Day, some people from rackspace etc
00:36:32 <cyeoh> as to how much pain that is going to cause them
00:36:58 <cyeoh> if there's any push back at all then we'd go the second route which is a lot more conservative
00:37:38 <cyeoh> maybe an email post to openstack-dev and openstack-operators would help?
00:37:59 <alex_xu> cyeoh, ok, I will send email to ask this problem
00:38:24 <alex_xu> cyeoh, thanks
00:38:32 <GMann> cyeoh: I have one on microversion + novaclient
00:38:46 <cyeoh> GMann: sure, go ahead
00:38:56 <GMann> Currently novaclient get the endpoitns from keystone for each service type.
00:39:09 <GMann> So for each microversion, we need to register separate service in keystone like devstack.
00:39:37 <cyeoh> GMann: no for microversions the endpoint is the same (unlike /v2 vs /v3
00:39:40 <GMann> That’s might be little bit ugly in case of many microversion.
00:39:56 <cyeoh> the microversion would be requested through an HTTP header instead
00:40:09 <cyeoh> like an Accepts header (exact format still to be defined)
00:40:20 <GMann> ohk.
00:40:28 <cyeoh> but kind of along the lines of the header which we currnetly send to the v2 api saying whether we want xml or json
00:40:28 <GMann> but for V2.1?
00:40:47 <cyeoh> well long term for V2.1 we'd be exporting as /v2
00:41:12 <cyeoh> if someone wants to expose it as /v2.1 in the meantime then yes they'd have to do some keystone stuff
00:41:30 <cyeoh> there is also a suggestion that we should just drop the whole /v2 or /v2.1 prefix once we have microversions
00:41:37 <cyeoh> because it no longer really makes any sense
00:42:00 <cyeoh> but thats quite long term and we'd need to support the /v2  prefix for a very long time anyway
00:43:02 <GMann> Ohk. Got it.
00:43:29 <GMann> Cyeoh : Thanks for clarification
00:43:35 <cyeoh> np
00:43:46 <cyeoh> anything else for open discussion from anyone?
00:44:34 <oomichi> during v2.1 API developing, we need to run v2, v2.1 and v3 in paralell. so we need to change devstack for adding v2.1 endpoint.
00:45:02 <oomichi> I guess just it would be temporary.
00:45:03 <cyeoh> oomichi: yea that's a pain, but I don't see any alternative to make sure that we don't regress the underlying v3 code
00:45:14 <cyeoh> hopefully that's just a juno thing
00:45:33 <oomichi> cyeoh: yes, agree.
00:46:02 <GMann> but if we take case of Tempest, then devstack endpoint might not be needed
00:46:49 <GMann> as Tempest has smart logic of converting the v2 endpoints to any version (v2.1) base on API_version on service client side
00:46:57 <cyeoh> I think the endpoint itself for devstack doesn't really hurt - if anything it makes it easier for people to test v2.1 if they want to
00:47:15 <cyeoh> the main pain is  having to do tempest testing for v2, v2.1 and v3
00:48:14 <oomichi> cyeoh: if disabling v2 XML API tests in tempest instead, the pain/cost can be reduced.
00:48:32 <tomoe_> hi nati_ueno: are you around?
00:48:36 <cyeoh> oomichi: yes that's true. Hopefully a decision will get made around that soon
00:48:42 <nati_ueno> tomoe_: hi!
00:48:50 <nati_ueno> tomoe_: I removed ordering part from bp
00:49:07 <tomoe_> did my comment  make sense?
00:49:11 <nati_ueno> tomoe_: yes
00:49:22 <tomoe_> i haven't caught up on the BP yet
00:49:30 <tomoe_> ok, cool
00:49:33 <nati_ueno> tomoe_: OK please review latest one
00:49:39 <GMann> yes, XML disabling will be very helpfull
00:49:39 <nati_ueno> tomoe_: now it is just union
00:49:55 <tomoe_> nati_ueno: will do
00:50:08 <oomichi> tomoe_, nati_ueno: is it related to nova api meeting?
00:50:18 <nati_ueno> oomichi: no
00:50:23 <tomoe_> oops. sorry, my bad
00:50:27 <tomoe_> bad channel
00:50:28 <nati_ueno> ohhh
00:50:29 <nati_ueno> sorry
00:50:34 <oomichi> np
00:50:41 <tomoe_> my bad sorry, getting out of here.
00:50:58 <cyeoh> np :-) Is there anything else for open discussion now?
00:52:15 <cyeoh> ok we might as well finish a bit early then :-)
00:52:19 <cyeoh> thanks everyone!
00:52:31 <oomichi> thanks all!
00:52:33 <alex_xu> thanks all
00:52:36 <GMann> thanks all. Have a good day.
00:52:41 <cyeoh> #endmeeting