12:00:04 <alex_xu> #startmeeting nova api
12:00:05 <openstack> Meeting started Fri Jun 12 12:00:04 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:21 <alex_xu> hello everyone!
12:00:30 <gilliard> Hello !
12:00:47 <eliqiao1> hi alex_xu
12:00:57 <alex_xu> eliqiao1: hi
12:01:50 <alex_xu> waiting one more minutes if more people join
12:01:55 <sdague> hey
12:02:08 <alex_xu> sdague: hey
12:02:30 <alex_xu> #topic status liberty works
12:02:42 <alex_xu> #link https://etherpad.openstack.org/p/liberty-api-working-list
12:02:57 <alex_xu> let us go through work items listed in liberty-1
12:03:17 <alex_xu> #link https://review.openstack.org/188410
12:03:28 <alex_xu> microversion novaclient support
12:03:45 <alex_xu> sdague: already give good comment, and I agree with him
12:04:16 <alex_xu> which missing some detail about how to implement in nova code. but hope people continue to review it
12:04:32 * alex_xu need more review on it also
12:05:01 <alex_xu> any question to this item?
12:05:16 <sdague> so I think that there is some confusion in responses there
12:05:35 <sdague> "I disagree with this statement. The latest microversions supported by bit client and API can be different for different commands(servers.create, keypairs.create). Cache can help only for number of similar calls, so do we need it at all?"
12:05:47 <sdague> I think that's a fundamental misunderstanding of how microversions work
12:06:19 <sdague> being a global version, not a per call concept (though it could be changed per call)
12:06:43 <sdague> I'm wondering if there is some communication / clarification that could be made to make that better
12:06:50 <sdague> so people are less confused by that
12:07:38 <alex_xu> although we have some doc about api microversion, but still have some confuse
12:07:41 * gilliard needs to read all those comments...
12:08:27 <alex_xu> sdague: do we want to implement version lazy checking, as we return min/max version when requested version didn't supported
12:09:59 <sdague> alex_xu: lazy in which sense?
12:10:09 <sdague> can you give me a scenario?
12:11:10 <alex_xu> sdague: the client shouldn't query version by version api first. The client can send actualy api request, then check the response, if 406 return means version didn't supported, then we client choice another version based on response
12:11:25 <alex_xu> sdague: maybe I shouldn't call it as lazy
12:11:52 <sdague> alex_xu: yeh, for the 'cli' use case, I think that's fine
12:12:04 <sdague> for the 'api' use case, I think we should be explicit
12:12:32 <alex_xu> sdague: agree, maybe a parameter to control whether check the version when construct client obj
12:12:32 <sdague> in the cli use case we should cache that version that we're going to start using so we aren't doing double duty all the time
12:12:47 <sdague> alex_xu: well, honestly, just put the retry logic in the cli layer
12:13:11 <sdague> the api call fails, the cli then constructs a new restclient with the new version
12:13:26 <johnthetubaguy> I keep wondering if we should make python-novaclient just focus on the CLI use case, if we can get the openstack SDK helping folks sooner, but thats probably a different conversation
12:13:28 <sdague> keeps the implementation cleaner
12:13:56 <johnthetubaguy> we need it working before we do that I guess
12:14:14 <sdague> johnthetubaguy: so... that would be nice, but I think we need to do this now. We have potential consumers already with the ec2 api and heat in our own community that need this stuff
12:14:20 <alex_xu> sdague: so in api it always check after actualy api call?
12:14:48 <johnthetubaguy> sdague: very true
12:16:00 <sdague> alex_xu: well if RestClient is constructed with a microversion, and it fails, then it fails.
12:16:11 <sdague> and the cli piece of code does the recovery
12:16:29 <sdague> which realistically would be how you'd expect other users would use it
12:16:53 <alex_xu> sdague: ok, got it
12:17:24 <alex_xu> anymore question,then let's move on?
12:17:33 <sdague> alex_xu: so how do we get that explained correctly in the spec?
12:17:42 <sdague> who has the todo to get that back into there?
12:18:12 <alex_xu> sdague: would you want to? I think you can explain that better
12:19:25 <alex_xu> sdague: you mean just comment on the discussion on it?
12:19:47 <sdague> ok, I can provide more comments there
12:19:56 <alex_xu> sdague: thanks
12:20:14 <alex_xu> #link https://review.openstack.org/#/c/189218/
12:20:15 <sdague> #action sdague to provide more detailed approach on novaclient microversions in the spec
12:20:32 <sdague> alex_xu: ok, I'm just about to push my add there
12:20:40 <alex_xu> sdague: thanks
12:21:03 <alex_xu> which spec already merged, but as sdague point it out, it isn't expected as we discussed yesterday
12:21:18 <alex_xu> so waiting for sdague spec
12:21:32 <sdague> #link https://review.openstack.org/191033
12:21:35 <sdague> hot off the presses
12:21:40 <alex_xu> and thanks to edleafe to be volunteer work on it, I will help on also
12:21:47 <sdague> so, basically, it's pretty close to what you had
12:22:11 <sdague> except one more bit about trying to make the new code directory structure look like the rest uri structure
12:22:16 <sdague> as much as possible
12:22:31 <sdague> to make it easier to keep the model in your head of how the api ends up looking
12:22:57 <sdague> I also just thought we should call the v2/ directory legacy-v2/ to make sure people realize it's not what they want
12:23:01 <alex_xu> quick throught you want to structure it as resource
12:23:20 <alex_xu> +1 legacy-v2
12:23:58 <sdague> alex_xu: yes, basically. For instance, which pieces of the code expose top level resources, and which pieces expose resources / info on other resources should be clear from the tree itself
12:24:38 <sdague> anyway, it's an idea, people should see if they like it
12:24:50 <alex_xu> sdague: yea, sound like good idea
12:25:02 * alex_xu will review it after the meeting
12:25:38 <alex_xu> next one is microversion guideline in api-wg
12:25:45 <alex_xu> #link https://review.openstack.org/187112
12:26:01 <alex_xu> #link https://review.openstack.org/187896
12:26:19 <alex_xu> And one more thing come up is Neutron is going to implement Microversion also
12:26:28 <alex_xu> #link https://review.openstack.org/#/c/136760
12:26:44 <alex_xu> From spec, there is a little different with nova and ironic implementation. And I commented on. Unfortunately it already merged… But I talked with Neutron core Salvatore, he will check my comment.
12:27:06 <alex_xu> And two things I have question from neutron's spec review
12:27:22 <alex_xu> One is experimental flag, we mention that flag in the nova spec, but we didn't implement it. Or say we didn't have
12:27:24 <gilliard> Good one.
12:27:24 <alex_xu> Chance to use that flag yet. Do we still want to support it?
12:27:57 <gilliard> I don't think we'll know about that until more operators are using kilo, tbh
12:28:30 <gilliard> Because it's a mechanism for them, isn't it?
12:28:51 <alex_xu> gilliard: I feel experimental flag also means an process of introduce new api
12:29:35 <sdague> yeh, the experimental flag was more transition for out of tree extensions
12:29:54 <sdague> we don't want to support it
12:29:58 <gilliard> I'd be happy to get rid of it right now, but then I don't run a cloud with proprietary extensions...
12:30:49 <gilliard> I think we need to keep it in the spec, and probably provide more detail about what it's for.
12:30:52 <alex_xu> as neutron have such requirement, we can introduce that flag api-wg, but we didn't support that looks like ok, it won't break anything, right?
12:31:38 <sdague> yeh, I suppose, we should recommend against it though
12:32:29 <alex_xu> ok, I will put that flag back to api-wg guideline
12:32:50 <alex_xu> Another question is vendor specific api. Neutron propose vendor specific api can support microversion which is decided by implementor. So do we have plan to support vendor specific api? And need think whether propose the vendor's microversion header to api-wg guideline
12:33:04 <sdague> we specifically do not
12:33:07 <johnthetubaguy> sdague: we should clear up messaging on that, but I think we left it as a way to report you have a non-standard API, and it being bad
12:33:24 <johnthetubaguy> yeah, we are killing and vendor API on purpose
12:33:25 <sdague> we don't want vendor specific stuff
12:33:29 <sdague> right, exactly
12:33:50 <sdague> and I think the api-wg should recommend against allowing vendor specific apis in
12:33:55 <johnthetubaguy> neutron is currently doing the exact opposite around that in general, hence the split up of all their plugins into different git repos
12:34:05 <johnthetubaguy> but thats a different discussion
12:34:14 <sdague> well, there are different slices in neutron still
12:34:20 <johnthetubaguy> sdague: +1 for adding a proposal to the API-WG
12:34:38 <johnthetubaguy> sdague: yeah, that comment was a bit unfair
12:34:46 <sdague> I have to cut a little early to deal with some errands this morning, will read scrollback later
12:35:05 <alex_xu> sdague: ok
12:35:35 <alex_xu> next one is polcy cleanup
12:35:45 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-api-policy-final-part,n,z
12:36:07 <alex_xu> it closed to finished, just need more review
12:36:21 <alex_xu> some of patch need update also
12:36:31 <alex_xu> hope we can merge them all in l1
12:36:54 <alex_xu> I think there isn't too much question as this is old stuff
12:37:07 <alex_xu> let us move on
12:37:18 <alex_xu> relax jsonschema
12:37:25 <alex_xu> #link https://review.openstack.org/#/c/173243/
12:37:57 <alex_xu> as the discussion in irc today, one change to the spec is we should ignore any extra headers include version request header
12:38:04 <johnthetubaguy> alex_xu: is that stuff listed on the priority etherpad?
12:38:34 <alex_xu> johnthetubaguy: yes, in https://etherpad.openstack.org/p/liberty-api-working-list liberty 1 works
12:39:06 <johnthetubaguy> alex_xu: no one is going to read that outside this group though... we have the central list we have asked groups to use here: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
12:39:34 <johnthetubaguy> just like last release, basically
12:39:39 <alex_xu> johnthetubaguy: oops, you mean put that in review list?
12:39:48 <johnthetubaguy> yeah, sorry, I was totally unclear!
12:40:15 <johnthetubaguy> but I am asking cores and non-cores to pay close attention to what is in that central etherpad
12:40:26 <johnthetubaguy> that will be easier when there is lots of stuff in there
12:40:40 <johnthetubaguy> saves people having to know one million etherpad locations
12:40:50 <johnthetubaguy> hopefully it helps, if not, we can try something else
12:41:16 <alex_xu> johnthetubaguy: I think it is useful
12:41:34 <alex_xu> johnthetubaguy: we should put that one to the review list when spec updated as the discussion
12:41:40 <eliqiao1> +1 , central is good idea.
12:41:50 <eliqiao1> s/central/central etherpad/
12:43:10 <alex_xu> johnthetubaguy: https://etherpad.openstack.org/p/liberty-api-working-list just for nova api team list what we need work on. status each item status.
12:43:12 <johnthetubaguy> alex_xu: my big worry for all priorities right now is that we don't have all the specs we need up for review yet
12:43:12 <eliqiao1> how about put that central etherpad link into spec or nova code or some easy reach where
12:43:21 <alex_xu> track each item status
12:43:26 <johnthetubaguy> given the deadline for blueprint freeze in a week or two
12:43:52 <johnthetubaguy> alex_xu: you can do that in the main etherpad too, and others can see that effort
12:44:13 <alex_xu> johnthetubaguy: should be in this one https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items?
12:44:33 <johnthetubaguy> alex_xu: yeah, true
12:44:53 <alex_xu> johnthetubaguy: ok, let me move the stuff
12:45:22 <alex_xu> #topic opens
12:45:42 <alex_xu> anything want to discuss?
12:46:08 <johnthetubaguy> ndipanov was asking about this: https://review.openstack.org/#/c/188913/
12:46:30 <ndipanov> thanks johnthetubaguy
12:46:33 <johnthetubaguy> about needing an API bump, and therefore a spec
12:46:57 <ndipanov> I will admit I did not read the whole thread on the ML
12:47:13 <ndipanov> but if the point of api versions is to have meaning to the end user, then this is silly to version
12:47:18 <alex_xu> yea, as the policy of bump version, anything need client to ware about should bump te version
12:47:49 <alex_xu> ndipanov: but provide more strict validation means beak some user, even some user use the api with wrong way
12:47:59 <johnthetubaguy> alex_xu: but this doesn't create a new error code for the client to understand?
12:48:13 <alex_xu> ndipanov: that is why we want to relax valdiation for v2.1 under /v2
12:48:36 <ndipanov> alex_xu, I have to say I don't see the value in not breaking clients who are using this for the sake of purity
12:48:40 <ndipanov> it's a bugfix
12:48:47 <ndipanov> of a broken thing that would get ignored
12:49:01 <alex_xu> johnthetubaguy: emm... it's more about strict the validation I think
12:49:08 <johnthetubaguy> ndipanov: so most bug fixes might need a spec and API bump, so the client knows when it can expect new types of errors and what those mean
12:49:26 <johnthetubaguy> ndipanov: its a choice we have taken, and its quite overzealous
12:49:35 <ndipanov> johnthetubaguy, that's just...
12:49:37 <ndipanov> no words
12:50:05 <ndipanov> good luck
12:50:11 <johnthetubaguy> now, the issue we have, is we don't have enough examples to document this yet, which is why every change without a bump is getting a lot of debate
12:50:20 <johnthetubaguy> its simply not decided
12:50:39 <alex_xu> ndipanov: yea, I understand...I put that comment because as we say we should be careful any api change, and we just have microversion now, and we didn't have full policy how to bump the version yet.
12:50:52 <johnthetubaguy> ndipanov: if you added a new return code, like 409 where there was never a 409, we agreed that needs a bump
12:51:03 <ndipanov> sure that makes sense
12:51:15 <johnthetubaguy> right, now this one, I am on the fence about
12:51:44 <johnthetubaguy> basically I am on the fence as I keep screwing up these choices, and people point massive holes in my logic
12:51:57 <johnthetubaguy> I don't see any reason why it has to be bump here
12:52:05 <ndipanov> I mean
12:52:13 <ndipanov> if versions are supposed to have meaning for the user
12:52:22 <johnthetubaguy> I just don't feel I can say its OK with out a bump, I want a second opinion, but I want to have a good reason explain to me
12:52:24 <ndipanov> then this should not be a version bump
12:52:36 <ndipanov> before it would just not work
12:52:37 <alex_xu> johnthetubaguy: +1
12:52:38 <ndipanov> and now it does
12:53:00 <johnthetubaguy> ndipanov: right, thats my thinking too
12:53:12 <johnthetubaguy> alex_xu: why do you think this needs a bump, I guess thats my question?
12:53:32 <ndipanov> changing a return code or adding a field - no question
12:53:39 <alex_xu> johnthetubaguy: emmm I just think about the client behavior
12:53:40 <ndipanov> but obvious brokenness
12:54:03 <alex_xu> let's move the dicussion back to openstack-nova
12:54:09 <alex_xu> it time to close the meeting
12:54:11 <ndipanov> ik
12:54:12 <ndipanov> ok
12:54:24 <alex_xu> #endmeeting