13:00:05 #startmeeting nova api 13:00:05 Meeting started Wed Jun 22 13:00:05 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:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:08 The meeting name has been set to 'nova_api' 13:00:11 who is here today? 13:00:16 o/ 13:00:40 * bauzas lurks a bit 13:01:04 wait one minutes for people join in 13:01:23 o/ 13:01:34 o/ 13:02:10 emm...i saw sdague around half a hour ago 13:02:11 \o 13:02:13 o/ 13:02:22 sorry, just getting more coffee 13:02:31 sdague: no worries 13:02:38 let's start the meeting 13:02:45 * edleafe is getting more coffee too 13:02:47 #topic actions from previous meeting 13:02:55 alex_xu to update policy docs to remove user_id references to server actions 13:03:05 there is one merged 13:03:06 #link https://review.openstack.org/#/c/325648/ 13:03:16 also have one for oslo.policy 13:03:28 #link https://review.openstack.org/325645 13:03:49 and one more for a note in nova devref 13:03:52 #link https://review.openstack.org/332643 13:04:33 that is all patches for remove user_id reference 13:04:42 s/is/are/ 13:04:54 just need review i guess 13:05:01 great, thanks 13:05:04 alex_xu: on https://review.openstack.org/#/c/332643/ 13:05:11 it says in the future user_id auth won't be supported 13:05:12 sdague: np 13:05:16 isn't that future as of like 2 weeks ago? 13:05:19 when legacy_v2 was dropped 13:05:30 mriedem: well, except we have a spec to add some back 13:05:32 mriedem: there is spec write by sdague 13:05:46 so it's confusing 13:05:52 it says in the future we're going to drop *all* support 13:05:56 but we have a spec to add some back in 13:05:58 #link https://review.openstack.org/324068 13:06:01 supporting user_id was a fluke, right? 13:06:06 mriedem: in the future we are going to drop all 13:06:13 which means that's just an additive spec :) 13:06:27 no regression, just something people figured out it was supported 13:06:30 https://review.openstack.org/#/c/324068/2/specs/newton/approved/user_id_based_policy_enforcement.rst@83 13:06:31 while it wasn't :) 13:06:54 i should ad more word to say there are few support for backward compatiable 13:07:05 Honestly, I think alex_xu's wording is fine 13:07:12 ok +W 13:07:16 i hadn't seen https://review.openstack.org/#/c/324068/2/specs/newton/approved/user_id_based_policy_enforcement.rst@83 13:07:19 thanks 13:07:19 there is just a bridge window here where it's not completely accurate 13:07:42 when are docs ever completely accurate :) 13:08:23 so, we are cool, let's move on 13:08:29 yeh, lets move on 13:08:29 mriedem to follow up with claudio on splitting up policy patch for easier review 13:08:42 i saw the patch splitted 13:09:12 #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/policy-in-code 13:09:35 and the base patch already merged 13:09:56 cool, I'll start looking at those today 13:10:02 cool 13:10:14 gmann to document that os-assisted-volume-snapshots is only implemented by the libvirt compute driver 13:10:29 I saw that patch and +2ed it 13:10:30 gmann: i remember i saw this patch, do you have link? 13:10:39 yea i rebased that one 13:10:41 ah, cool 13:10:43 #link https://review.openstack.org/#/c/326975/ 13:10:49 sdague: need +2 again :) 13:11:07 oh, merge conflict 13:11:17 mriedem to start openstack-dev thread on os-assisted-volume-snapshots 13:11:18 yea 13:11:23 related one 13:11:37 that's done, basically none of the cinder 3rd party ci that uses that API is working 13:11:53 and there doesn't appear to be any urgeny around that 13:12:10 mriedem: cool, thanks 13:12:30 gmann_ to write microversion change for 404 on API proxies 13:12:36 o/ 13:12:48 gmann: sorry...i just saw this action... i should check with before i start the patch 13:13:03 alex_xu: Thanks for patch, i was not getting time this week 13:13:07 alex_xu: np. 13:13:22 gmann: cool :) 13:13:26 alex_xu: your patch looks good to me otherwise i checked the code 13:13:42 #link https://review.openstack.org/332631 13:13:54 and if we want to return 404 early at wsgi we need hack to fetch url and version from request and return 404 13:14:02 this is going to return 404 for image api 13:14:06 right, gmann had a doc patch on the deprecation, did that merge yet? 13:14:08 so https://review.openstack.org/#/c/332631/ seems weird without a microversion bump 13:14:16 sdague: yea that is merged 13:14:18 #linl https://review.openstack.org/#/c/329357/ 13:14:29 there should be a bunch of patch for other api later, and the last patch will be https://review.openstack.org/332632 13:14:59 should we bump them in one patch? 13:15:03 mriedem: it's in the follow up patch 13:15:03 alex_xu: but if we land those early 404 changes, like https://review.openstack.org/#/c/332631/ 13:15:16 and then some other things land in between that and the last, 13:15:20 then the early one is wrong isn't it? 13:15:22 yeh 13:15:26 there are several changes up for 2.31 right now 13:15:29 i have one of them 13:15:36 mriedem: yea, we should merge those patch togetther 13:15:42 yea hypervisor one is another 13:15:49 so, actually, given the simplicity of https://review.openstack.org/#/c/332631/1/nova/api/openstack/compute/images.py 13:16:02 I kind of wonder if we should do all the proxies in one go 13:16:17 we can have quck for next two days, get all the thing ready, and merge them. 13:16:36 alex_xu: can you stage up the rest of the patches and see how complicated they are? 13:16:36 yea will be easy to merge 13:16:46 and then we can figure out how we want to group them 13:17:11 I think this is a good instance of -2 the bottom of the stack, build all the patches, and then figure out the landing order 13:17:21 so we know if this is 1 or more microversions 13:17:23 sdague: ok, no problem 13:17:32 sdague: +1, same thought 13:18:04 -2 applied 13:18:09 mriedem: cool 13:18:13 cool, just two -w 13:18:56 sdague: would be nice to get that in one microversion if we can, top idea 13:18:59 i will work on other patch tomorrow 13:19:25 johnthetubaguy: yea, one microversion 13:20:15 so we are cool, let's move on? 13:20:17 yeh, for everything besides networking, I think it's doable 13:20:20 networking, I'm not sure 13:20:38 ah, true... that one could be tricker 13:20:45 alex_xu: yeh, lets move on 13:21:09 emm...i need check networking tomorrow, maybe i miss something 13:21:18 sdague: may bwe we need another decorator for thsoe with neutron enabled etc 13:21:18 #topic API Priorities 13:21:49 current burndown - http://burndown.dague.org/ 13:21:51 sdague: anything for api-ref? 13:22:07 slow progress, we still knock out a few every week 13:22:15 is there any specific reason why no one has taken method verification for servers-multiple-create.inc ? 13:22:40 mriedem: guess just no one selected 13:22:43 mriedem: because it's a little complicated 13:22:50 sdague: yea, i will give some time on this on friday and let's see how many i can do 13:23:15 so, 13:23:23 maybe after 6/30 we plan another sprint 13:23:35 the week of 7/4 isn't good 13:23:45 honestly, the next month is pretty dicey for me 13:23:46 but maybe something the week of 7/11 13:24:12 TC thing in anarbor next week, then I'm off for 2 weeks, then nova midcycle 13:24:21 so my intent was more like early august push 13:24:23 trust falls in MI 13:24:31 and bacon 13:25:03 august could work looking at https://wiki.openstack.org/wiki/Nova/Newton_Release_Schedule 13:25:07 9/2 is n-3 13:25:17 and FF 13:25:20 so yeah early august 13:25:40 I'll start organizing once I get back off vacation 13:25:43 seems a good time for doc push to become normal 13:25:53 cool 13:26:10 ok, next? 13:26:26 we already hit up policy in code, there is a patch stack there 13:26:32 deprecated extension? 13:26:47 yea, most of things already touch 13:27:00 on the deprecate extensions front... 13:27:09 https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:fold_disk_config 13:27:20 that gets rid of the disk config and access ips extensions 13:27:36 i'll hit the bottom 2 after the meeting 13:27:39 since you updated them 13:27:54 mriedem: yeh, I think I got all your objections 13:28:10 glaring omissions? you mean 13:28:16 so encourge people to help on fold other extesnsion 13:28:33 I also have been deleting chunks of unused code in the process (starting to do as independent stacks so they don't get caught - https://review.openstack.org/#/c/332436/ ) 13:29:00 deleting the generator extension stuff was nice 13:29:07 those were just madness 13:29:23 yeah 13:29:56 alex_xu: my hope was to get through the update / resize / rebuild extensions and remove those to ensure we have a pattern that works 13:30:04 then have people go after them 13:30:33 the focus is really anything that modifies servers object either in or out 13:30:35 sdague: ok, cool 13:31:16 am i dreaming this or was there a spec for removing weirdo api extensions yet like os-cloudpipe and agent-build? 13:31:22 or was that another todo? 13:31:25 mriedem: it's on my todo list 13:31:33 so, 13:31:44 i feel like we're getting late in the cycle to be adding more api specs 13:31:48 it should be another spec i guess 13:31:48 given everything that's already loaded up 13:31:56 mriedem: yeh, that is probably quite true 13:32:04 our priorities for api were (1) policy in code and (2) docs 13:32:29 and we have a lot more going on than that, so i don't think we can probably do the freak extension deprecation in newton at this point 13:32:39 mriedem: I'm fine with that 13:32:45 which, meh, deprecating the proxies is more important 13:32:46 we can do that in ocata 13:32:48 yup 13:32:49 ok 13:32:54 yea, i'm cool also 13:32:54 right, I think the proxies are more important 13:32:57 +1 13:33:22 I also think that given the defcore kiveching around vendor extensions, getting rid of server extensions is important 13:33:43 yeah...that... 13:33:55 sdague: have you pointed that out in chris hoge's thread already? 13:33:57 because it looks like no matter how many times we say "don't do this" 13:34:00 i feel like someone did 13:34:08 people don't seem to get it - http://lists.openstack.org/pipermail/defcore-committee/2016-June/001124.html 13:34:11 but i can't read that thread anymore, it's never ending 13:34:22 :) 13:34:31 I have pointed out that it is going away, so has hodgepodge 13:34:31 because i think ^ is mostly around juno->kilo 13:34:45 once these clouds get to newton and their extension facility is gone, 13:34:50 right 13:34:50 i think we jump to open directly 13:34:53 they'll be freaking out again 13:34:59 #topic open 13:35:06 but i don't feel badly about that either 13:35:18 these are the same groups wanting to maintain stable/juno forever 13:35:24 now i know why 13:36:27 i don't have anything else 13:36:54 I have a change to erroring in api samples - https://review.openstack.org/#/c/332261/ 13:37:16 because as we fold in the extensions, it's good to have better errors to figure out what you did wrong 13:37:18 yea, i didn't reach that yet 13:37:28 oh, I had one other question on server views 13:37:47 why do we have the v21 subclass 13:38:05 sdague: probably no longer needed after dropping v2 13:38:13 https://github.com/openstack/nova/blob/656a3f4a174ad877151bca0612a8fa094793f34e/nova/api/openstack/compute/views/servers.py#L285 13:38:43 it looks like it might be because of how ext attributes on addresses expose 13:38:56 but curious if anyone else remembered more clearly 13:39:28 emm...i didn't remember why 13:39:54 was that left over from v3 maybe? 13:39:55 unsure 13:39:59 i figured it was just separate since it handles microversions 13:40:24 it should check the patch when we convert v3 to v2.1, then we will know why this subclass is keepting 13:40:44 addresses view is different https://github.com/openstack/nova/blob/656a3f4a174ad877151bca0612a8fa094793f34e/nova/api/openstack/compute/views/addresses.py#L48 13:40:52 i think it was before microversion changes in that 13:41:11 if anything ever passes extend_address=True 13:41:27 which v2.1 does here https://github.com/openstack/nova/blob/656a3f4a174ad877151bca0612a8fa094793f34e/nova/api/openstack/compute/views/servers.py#L285 13:41:46 https://github.com/openstack/nova/commit/e74b62f26fb949149eadcf8ab76c1d01d3e16748 13:42:34 looks like that's not used 13:43:28 shall we end the meeting and hash on this in the nova channel? 13:43:37 that was in since v3 13:44:06 yea 13:44:18 if no more thing to bring up, let us back to nova channel 13:44:48 3... 13:44:53 2.. 13:45:00 1. 13:45:06 ok, thanks all 13:45:10 #endmeeting