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