13:00:22 #startmeeting nova api 13:00:24 Meeting started Wed May 4 13:00:22 2016 UTC and is due to finish in 60 minutes. The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:28 The meeting name has been set to 'nova_api' 13:00:32 who is here today? 13:01:24 hi 13:01:39 o/ 13:01:41 o/ 13:02:21 o/ 13:02:26 i guess people still in jetlag 13:03:02 #topic API Priorities 13:03:13 o/ 13:04:17 let say remove legacy v2 API first? 13:04:41 +1 :-) 13:04:54 +1 13:05:12 oomichi_: and i already sent out some patches 13:05:15 #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/remove-legacy-v2-api-code 13:05:57 not only nova, but also devstack 13:06:08 https://review.openstack.org/#/q/status:open+project:openstack/topic:bp/remove-legacy-v2-api-code 13:06:12 is there any order people concerned? I'm think of removing the api-paste.ini entry first, that stop user using the legacy v2 api first. Then we remove legacy v2 code piece by piece 13:06:44 oomichi_: ah, cool, also the merged one, the legacy v2 gate job, thanks for that :) 13:07:16 alex_xu: yeah, we can remove api-paste.ini now 13:07:20 alex_xu: I left a comment on your patch removing the paste bits 13:07:25 honestly, as long as we get it done quickly, the order isn't too important 13:07:36 yeah, +1 sdague's comment on that patch 13:07:37 I'd like to have a unit test to understand what the user sees if they forgot to update paste.ini 13:08:11 I also updated the api dashboard to look for this blueprint - https://review.openstack.org/#/c/312475/ 13:08:17 sdague: yea, good point on that patch, I think I should add log in pipeline_facotry method instead of removing the pipeline_factory directly. 13:08:47 alex_xu: yeh, maybe, as long as we understand what the behavior is, and it's something that the admin will understand and be able to fix 13:09:02 the ec2 remove from enabled_apis was a little rougher than we would have liked 13:09:48 sdague: ok, got it, i will update the patch. 13:10:18 I think we should remove paste entry before breaking the legacy v2 api code 13:10:58 after that we can free to remove legacy v2 api code, just ensure the tests passed. 13:11:07 yep 13:11:19 I think we have to, it sounds sensible 13:11:40 after legacy v2 code removed, there can be some cleanup in the wsgi stack. 13:11:47 getting the paste entry removed, and the failure if it's still there sensible seems like the primary step. After that we can just delete a bunch of stuff. 13:12:20 one more question, what kind of test we expected on v2.1 compat mode? 13:13:19 alex_xu: meaning additionalProperties:True mode? 13:13:28 are we not OK with all the existing testing? 13:13:45 I think the existing testing is probably fine 13:14:09 the api sample test still run with v2.1 compat mode, the nova/tests/functional/test_servers run under compat mode, and other functional test is not. 13:14:12 oomichi_: yup 13:14:37 we've got functional testing for the APIs in tree with the samples, the only differences between it and the v2.1 code should be in that layer 13:14:54 I'm sure there are ways to enhance it further, but it's been fine up until this point 13:14:55 are we also removing the extensions config for v2.1, maybe I am getting ahead of the list now? 13:15:12 johnthetubaguy: I think we decided that's a spec 13:15:21 for communication as much as anything else 13:15:26 sdague: gotcha 13:15:55 I remember that conversation now... vaguely 13:16:03 ok, that is another question, but i got clearly now 13:16:11 https://etherpad.openstack.org/p/newton-nova-api L96 13:16:37 in my head that change affects the samples testing, hence the quick check 13:16:55 * mriedem joins late 13:17:28 yes, probably need gmann's sample test merging work first 13:18:18 who is going to write that spec? 13:18:51 if I don't write it, I can help +2 it 13:19:04 if no-one, let me help it. 13:19:11 I might get to it, but it will be a couple of weeks, because we really do need to stay focussed on api-ref and policy 13:19:56 ok, looks like api-ref and policy is more priority than that 13:21:11 so let me try first. 13:21:12 sounds like the correct call 13:21:32 so looks like cool at here. let's move on 13:21:50 api policy discovery 13:22:05 #link https://review.openstack.org/#/c/290155/ 13:22:17 we said only need this one in newton? 13:22:53 looks like alaski and dhellmann need to sort that one out 13:23:00 otherwise i was more or less ok with it 13:23:10 yeh, we should just keep on top of it, I think I need to take one more pass on it 13:23:23 likewise, I like the way its going, just nits 13:23:36 i'm not sure if dhellmann is asking that we bake a bunch of new stuff into an oslo lib 13:23:42 still implement in nova first, not oslo? 13:23:44 because it would be easier for nova to do this thing first and split it out later 13:24:09 ok, got it 13:24:22 ok, probably a todo to sort out where that one stands 13:24:28 to make sure we get to approval soon 13:24:41 it needs a rev anyway 13:25:04 but it would be good to have an agreement between alaski and dhellmann 13:25:08 https://review.openstack.org/#/c/289405/6/specs/newton/approved/discoverable-policy-api.rst is a bit more problematic. I think we decided on a very different approach during the session, but I'm not sure that claudio_ was there 13:25:34 ah, yes, the nova-manage command idea 13:25:46 right 13:25:57 * mriedem doesn't remember exactly 13:26:00 I can provide that group feedback into the spec today 13:26:02 hopefully the notes are in https://etherpad.openstack.org/p/newton-nova-api 13:26:22 https://etherpad.openstack.org/p/newton-nova-api L28-L41 13:26:44 yeah 13:26:45 L35 is the most relevant 13:26:47 new policy language 13:26:50 at line 35 13:26:51 Decision: no, not in Newton. Build the infra and be able to see it in nova-manage. 13:26:52 build it into nova-manage 13:26:56 yup 13:26:56 Decision: don't munge this with capabilities, this is a permission check. +1 13:27:15 i would have gotten there eventually :) i need to write the recap for the api session today 13:27:34 :) 13:27:52 #action sdague to provide session feedback to https://review.openstack.org/#/c/289405 spec 13:28:13 sdague, awesome, because I'm struggling to parse the etherpad 13:28:19 quick question... 13:28:22 sdague: cool, thanks 13:28:41 actually is dumb question, ignore me, was thinking about whats needed to unblock live-reize 13:28:51 this is a dependency, but its not the end of the road, thats all 13:28:58 johnthetubaguy: right, we said, previously, it was discoverable capabilities 13:29:12 which this is all ground work for 13:29:22 yeah, +1 13:29:31 you could expose that via permissions, but thats messy 13:29:40 we specifically said we wouldn't do that 13:30:04 Decision: don't munge this with capabilities, this is a permission check. +1 13:30:09 L36 13:30:19 right, I was meaning deployers might change permissions due to known capabilities, but yeah, its not an assumption we want in the API 13:30:23 i still confuse on the policy discovery and capabilities discovery. I found we always talk about them together, but I thought they are diffrent things. 13:30:31 alex_xu: they are 13:30:48 does it work vs can i do it 13:31:10 but capabilities are hard to do without the policy being fully known in advance (which it is not) 13:31:22 ok, cool, looks like i'm same page with people 13:31:30 +1, this is a needed stop on that journey 13:31:40 because the two intersect in some cases, where the cloud can in theory do X, but the admin wants to prevent it 13:31:58 I think claudio_ was hoping this spec would un block his live-resize, hence my query 13:32:02 just a heads up there 13:32:05 so it makes no sense to expose can:live-resize to the user, they try, then get a 403 13:32:07 ah, i got it now, sdague thanks 13:32:15 sdague: agreed 13:32:34 or, it can make sense, but it's mostly very frustrating 13:33:02 ack, both for the deployer and the user 13:33:07 so if we fix permissions being fully explicit, then we can address the rest of it on top of that 13:33:46 I assume throughout this people being conscious of the fact that any one human operating a user-agent may have multiple identities with the service 13:33:57 so they need to be able to know "if you change who you are you might be able to do this" 13:34:02 after we have policy discovery, that is kind of thing instead of extension? 13:34:18 cdent: we were generally talking per token, I think 13:34:41 cdent: right, per token, which is really per tenant in the policy conversation 13:35:31 cool, just checkin' 13:35:32 alex_xu: more or less, but that's all next cycle 13:36:22 sdague: ok, want to know how people think about that, as we said no extension. but there is something make people can do something 13:36:29 s/something/same thing/ 13:36:45 so we can move on? 13:36:51 alex_xu: yeh 13:37:02 Let's talk about api ref 13:37:08 sdague: what is next plan 13:37:21 well, first off, a bunch of open patches out there - https://review.openstack.org/#/q/file:api-ref+project:openstack/nova+status:open 13:37:43 jichen is doing a bunch of great work here, very thankful of that 13:37:49 we need more folks diving in though 13:37:54 jichen: thanks! 13:38:08 alex_xu: sdague : :) 13:38:26 next Mon & Wed we'll do some doc sprints to try to push through as much as possible 13:38:48 #link api-ref review sprint dev thread http://lists.openstack.org/pipermail/openstack-dev/2016-May/093844.html 13:38:55 I've got some todos once we get the content close about microversions, and changing the way we represent urls 13:39:30 How about I follow up to mriedem's post with the details there so people can see the longer term steps here 13:39:55 +1 13:39:57 maybe separate thread if it's not about reviews? 13:40:10 i'd only follow up with review tips to my thread 13:40:16 mriedem: sure, sounds good 13:40:19 this is what to expect, this is what to chec, etc 13:40:21 *check 13:40:36 I'll follow up on your thread with that, I'll wait until post sprint to evaluate and say next steps 13:41:06 I'll probably write something today to assess how many outstanding items we've got in our checklist 13:41:35 I updated the nova-api dashboard to put API ref at the top 13:41:53 to try to score everything there first, as it should be easy 13:43:08 any other questions there? 13:43:22 nothing fro me 13:43:27 s/fro/from/ 13:43:32 link to the dashboard? 13:43:35 or is that in a wiki somewhere? 13:43:38 or etherpad 13:45:18 mriedem: it's just in the repo, I can add it to the wiki 13:45:29 mikal thanks you already 13:45:43 or figure out a way to get these dashboards on stable urls 13:46:20 there is 14 minutes left with a few more items, so let's move on 13:46:32 ok 13:46:33 Deprecated API Proxy 13:46:50 #link https://review.openstack.org/#/c/312209/ 13:46:59 i plan to review that soon 13:47:06 we have notes in the session etherpad 13:47:41 yeh, I think that mostly matches the session 13:47:58 ok, only thing need is review 13:48:28 if no more question, then move on? 13:48:32 yep 13:48:39 #topic Open 13:48:53 cdent: you have items for open I think 13:49:09 yeah, I am after eyes and feedback on https://review.openstack.org/#/c/305800/ and https://review.openstack.org/#/c/300077/ 13:49:22 did you guys already go over the legacy v2 api removal? 13:49:28 the main concern is how best to document the change and ensure that it is kosher 13:49:31 mriedem: that was first 13:49:37 d'oh! 13:49:37 mriedem: yea, in the beginning of the meeting 13:49:38 ok 13:50:13 I have on my todo list a few more specs to write up: deprecating some unused, unusable REST APIs; remove of bookmark links; update for the flavor by server spec; 13:50:22 I know that the microversion change isn't a priority, but it is a) basically done b) pretty lightweight, so may as well push it along if people have some spare cycles 13:50:59 my implementation is probably a bit incomplete, due to my inexperience with nova api changes, so feedback will make things happen 13:51:10 cdent: yeh, I'll put the spec up for review. I think it's mostly going to be about a usage section in api-ref on microversions 13:51:21 starred that spec to look later 13:51:25 thanks 13:52:02 ah, good point, probably a lot of microversion doc need update 13:52:14 https://review.openstack.org/#/c/311529/ is the metadata casing proposed fix 13:52:45 which was talked about late on friday, and mriedem did a good job pointing out the bits I messed up in draft 1 13:52:51 draft 2 should be a lot more explicit 13:53:19 http://docs-draft.openstack.org/29/311529/3/check/gate-nova-specs-docs/7f935cf//doc/build/html/specs/newton/approved/lowercase-metadata-keys.html 13:53:57 * mriedem frames that on the wall 13:54:13 cool, another fix for mess stuff 13:55:37 oh, before I forget, mriedem had said something about wanting it to be easier to explore what gabbi is, so I made this: https://gist.github.com/cdent/d70015ac6fffbbd3cd80a771e197bf36 13:55:37 if no more question, I probably go to end the meeting early? 13:55:51 it's a shell script that automatically starts up and automatic demo 13:55:56 s/and/an/ 13:56:04 in case anyone is interested or curious 13:56:25 cdent: cool 13:56:26 cool 13:56:40 cdent: oh, last thing, I looked at the resource pools API spec this morning 13:56:51 and I wonder if now is the time to split the CLI as well 13:56:56 it only covers the very basics, mostly of the syntax, not of how to integrate with testing harness and fixtures 13:57:00 so we don't have to do that late in the game 13:57:02 sdague: yeah I read that 13:57:08 I think you're probably right 13:57:09 and take a bunch of novaclient gorp with it 13:57:34 I haven't even begun to think that about the cli yet... 13:57:40 s/that// 13:57:52 split the cli as in for the new placement api? 13:58:00 mriedem: yeh 13:58:13 and put it where? new thing or osc? 13:58:22 probably a new thing entirely 13:58:26 * alex_xu will cut the meeting on time, but now people can just free to talk 13:58:48 I guess it could be an osc plugin, which would be fine 13:59:16 but not in nova cli for sure, because that will be one more bit of split challenge 13:59:22 #endmeeting