13:00:00 <alex_xu> #startmeeting nova api
13:00:01 <openstack> Meeting started Wed Jun  8 13:00:00 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:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:05 <openstack> The meeting name has been set to 'nova_api'
13:00:11 <alex_xu> who is here today?
13:00:14 <edleafe> \o
13:00:19 <jichen> o/
13:00:19 <mriedem> o/
13:00:19 <johnthetubaguy> o/
13:00:24 <gmann_> hi
13:00:41 <sdague> o/
13:01:08 <alex_xu> hello everyone, let's start the meeting
13:01:16 <oomichi_> hi
13:01:19 <alex_xu> #topic actions from previous meeting
13:01:28 <Kevin_Zheng> o/
13:01:32 <alex_xu> action sdague to write up a spec about limitted (and deprecated) user_id support in policy in nova
13:01:42 <alex_xu> #link https://review.openstack.org/#/c/324068/
13:02:36 <alex_xu> sdague: looks like it is waiting for more feedback
13:02:59 <sdague> yeh, pretty much
13:03:33 <alex_xu> one question, does it mean we didn't want to check policy with target in the future? if we want to check policy with target in the future, that means user can enforcement policy by user_id also.
13:03:37 <sdague> the only real -1 is over my language about "not being openstack"
13:03:51 <sdague> alex_xu: it does mean that
13:04:05 <alex_xu> sdague: ok, got it, clear now
13:04:06 <sdague> the unit of permissions should be a project
13:04:23 <sdague> keypairs is the only place where that is weird....
13:04:42 <sdague> but in general we should be talking about projects here
13:04:54 <sdague> I tried to make this the smallest list possible
13:05:09 <sdague> and responding to jichen unlock and unpause are specifically left out
13:05:32 <alex_xu> ok, without target, the policy discovery become easy also
13:05:37 <sdague> alex_xu: yep
13:06:24 <alex_xu> action: alex_xu to update policy docs to remove user_id references to server actions
13:06:24 <sdague> the modern interpretation of policy is really project based
13:06:43 <sdague> but it was a json file so people did crazy things in the past, and no one realized :)
13:07:05 <johnthetubaguy> so this all seems good, it seems I didn't submit my comments, but I was just wondering about changing the text for that "not openstack bit", I agree with what you mean though
13:07:20 * johnthetubaguy nods at crazy things
13:07:44 <sdague> johnthetubaguy: yeh, we can word smith that for sure
13:08:01 <alex_xu> sdague: not only keypair, also keystone use user_id, that was found when i update doc for user_id
13:08:01 <sdague> alternative language is helpful, I was trying to get a first draft out there with the actions list detailed
13:08:13 <sdague> alex_xu: well, keystone *is* different
13:08:20 <mriedem> #action alex_xu to update policy docs to remove user_id references to server actions
13:08:21 <sdague> because keystone is about users
13:08:30 <johnthetubaguy> sdague: totally, that list was the new data, and seems like an OK minimal list to me
13:08:31 <sdague> so, in keystone, it's fine
13:08:37 <alex_xu> #link https://review.openstack.org/325645
13:08:48 <alex_xu> #link https://review.openstack.org/#/c/325648/
13:09:10 <sdague> but all other projects are about resources owned by projects, and that should be the permissions model
13:09:21 <alex_xu> mriedem: yea, it was done, one of merged. due to keystone use it, i just added note about user_id and remove the wrong example for nova
13:09:32 <johnthetubaguy> sdague: +1
13:09:48 <johnthetubaguy> so folks can be in multiple groups, and groups of one
13:09:50 <sdague> alex_xu: yeh, merging that doc fix is good
13:09:54 <sdague> johnthetubaguy: right
13:10:05 <mriedem> i suppose cinder has this same issue probably
13:10:23 <mriedem> and likewise manila, and maybe other projects that were created from nova
13:10:24 <sdague> I think it also really shines a light on the hierarchical projects use case
13:10:31 <johnthetubaguy> sdague: +1
13:11:03 <sdague> because it turns out that hierarchical projects often don't need dedicated quotas :)
13:11:15 <gmann_> yea, glance too, i remember some test case update for thsoe
13:11:18 <sdague> which is the hard problem that basically jammed up any future progress
13:12:11 <sdague> mriedem: yeh, it might be. I think it's somewhat on those projects to keep an eye on it.
13:12:57 <mriedem> we didn't know about it until the operators brought it up right?
13:13:23 <mriedem> a courtesy heads up to the general dev list might be useful for xp stuff, even though there is a thread in the ops list
13:13:25 <mriedem> just a thought
13:14:04 <sdague> yeh, let's get the spec evolved first
13:14:12 <mriedem> sure
13:14:24 <sdague> I honestly think that cinder is the only likely place with similar issues
13:14:35 <sdague> given the use cases that came forward
13:14:52 <mriedem> btw, the abstract on your spec,
13:14:56 <mriedem> exceptionally flowery - good work
13:14:59 <mriedem> you said it would be
13:15:52 <johnthetubaguy> well it is a big anniversary of Shakespeare this year
13:15:54 <sdague> mriedem: :)
13:16:17 <sdague> you have to do something to make it so people don't fall asleep reading specs
13:16:34 <johnthetubaguy> sdague: I certainly appreciate that, rightly or wrongly
13:16:58 <sdague> ok, so I think we've covered that, please review the spec
13:17:01 <sdague> next topic?
13:17:16 <alex_xu> yup
13:17:35 <alex_xu> #topic API Priorities
13:18:00 <alex_xu> api-ref first
13:18:07 <alex_xu> sdague: any news?
13:18:29 <sdague> we're down below 100 tags left - http://burndown.dague.org/
13:18:53 <sdague> the 0.3.0 os-api-ref went out on friday
13:19:05 <sdague> that makes open/close sections stateful in the url
13:19:14 <sdague> and fixes a microversion parsing issue so 2.1 != 2.10
13:19:33 <alex_xu> heh, cool
13:19:38 <sdague> and... there is a microversion selector, though it requires a conf add to nova
13:19:44 <gmann_> wow, nice data presentation.
13:19:45 <sdague> I'll push a review for that
13:20:07 <gmann_> sdague: you mean drop down selector for  microversion ?
13:20:27 <sdague> I was talking to mugsie, we'll probably have a pop up os-api-ref meeting for the rest of the cycle to work through items on it
13:20:57 <sdague> he's got a conversion to using the new openstackdocstheme that the rest of the docs moved to, but we have to be careful in how we cut folks over
13:21:12 <gmann_> sdague: but we are adding the microversion attributes in extising api-ref, do we need to undo thsoe?
13:21:26 <sdague> gmann_: undo what?
13:21:37 <gmann_> i did not completly uderstood the benefit of adding those in v2.1 ref
13:22:12 <gmann_> like -https://review.openstack.org/#/c/325308/
13:22:14 <alex_xu> gmann_: i guess you will understand after you see the sample from sdague
13:22:31 * alex_xu try to find the link
13:22:43 <sdague> gmann_: http://developer.openstack.org/api-ref/compute/?expanded=list-servers-detail
13:22:53 <sdague> for the same reason as things like ip6 and the like
13:23:00 <sdague> and tags
13:23:18 <alex_xu> here is https://dague.net/testing/api-ref/
13:23:27 <johnthetubaguy> adding that detail was really the point of the whole move
13:23:39 <sdague> right, but even without the selector, the "New in" is important
13:23:52 <sdague> just think about the entire python stdlib document
13:24:12 <gmann_> but example shows v2.1 response only which can be confusing?
13:24:25 <gmann_> because first thing people look is on example
13:25:22 <sdague> gmann_: if people are only going to look at examples, and not at the parameter definitions, there isn't much we can do about it
13:25:54 <sdague> it's fine if we specify which version number the response / request for the example is based on
13:26:04 <gmann_> sdague: true but i was thinking if we adding microversion attribute in param then example also should include those.
13:26:25 <gmann_> or we show max microversion response/request
13:26:32 <gmann_> for that API
13:26:36 <sdague> gmann_: maybe, though I think the example is that, an example
13:26:39 <sdague> to show some structure
13:26:47 <sdague> the parameter list is actually the definition
13:27:04 <johnthetubaguy> once we have that selector across the top, I think we can change the examples to the "newest" example, but thats a follow up extra thing once we have the main data in there, I think
13:27:08 <sdague> no API doc you've ever read has an example for every possible perterbation of parameters
13:27:33 <sdague> johnthetubaguy: I'm also honestly a little unconvinced the selector is going to be clarifying vs. just more confusing to new folks
13:27:43 <gmann_> yea they do not most of the case
13:27:52 <johnthetubaguy> sdague: thats true, I just wonder about examples that are invalid in the latest version
13:28:04 <sdague> johnthetubaguy: invalid is definitely different
13:28:14 <sdague> and I agree that we should be careful about that
13:28:20 <johnthetubaguy> we could go for always show the newest samples, but thats also confusing, as it often includes stuff that is not available in the base version
13:28:30 <johnthetubaguy> I think what we have is the best starting point
13:28:32 <sdague> but... we only have 1 instance of that around the service API right?
13:28:43 <sdague> I guess the block device name as well
13:28:43 <gmann_> as we have sample for ech version then we can include those per version
13:28:47 <mriedem> e.g. os-getVNCConsole Action and the other type-specific consoles are dead in like 2.5?
13:28:57 <sdague> mriedem: yeh
13:28:58 <johnthetubaguy> I was thinking about live-migrate removing params
13:29:39 <sdague> so we have a handful, and we're going to need to handle those. But I think we should think about this again as human first content
13:29:40 <johnthetubaguy> anyways, its way better than before, where there was zero information
13:29:46 <gmann_> sdague: johnthetubaguy i was thinking if version selector bring up the new param in list
13:30:00 <gmann_> johnthetubaguy: +1
13:30:04 <sdague> so not build some random hide / show infrastructure for everything, but actually explain, in words, here is an example for X.Y
13:30:15 <sdague> in X.Z we removed this parameter, so it now looks like
13:30:23 <johnthetubaguy> yeah, the words I think are needed here
13:30:32 <johnthetubaguy> we could have an example for each edge in each section
13:30:40 <sdague> documentation is communication, words are needed when things aren't obvious
13:30:52 <mriedem> that would help with get me a network, because today i'm just updating the description with notes https://review.openstack.org/#/c/316398/9/api-ref/source/parameters.yaml
13:30:55 <sdague> but that's human judgement
13:31:05 <mriedem> would be good to show an example for the v2.31 microversion for get me a network
13:31:11 <sdague> mriedem: yeh, get me a network is a good instance
13:31:28 <mriedem> it changes server.networks to required and adds new values for networks.uuid, so it's wonky
13:31:31 <sdague> mriedem: yep, fortunately, we can just add another chunk of examples super easy, it's just another include :)
13:31:38 <mriedem> yeah
13:31:57 <gmann_> so if we have example for each version that will be more clear to understand each version update
13:32:33 <sdague> gmann_: honestly, no
13:32:42 <sdague> it will just get super confusing at times
13:32:47 <johnthetubaguy> yeah, thats going to be a disaster
13:32:50 <sdague> explain it with words about what is different
13:32:53 <mriedem> yeah, comparing json blobs with my human eye fails
13:32:58 <sdague> mriedem: ++
13:33:10 <gmann_> sdague: yea with word in param definition
13:33:14 <alex_xu> good point~
13:33:32 <gmann_> but where we are going to show microversion's response exmple etc
13:33:56 <sdague> gmann_: we don't need to show every single possibility
13:33:56 <alex_xu> it's good to have sample when structure changed.
13:34:28 <gmann_> sdague: hummm
13:34:30 <sdague> also, http://www.sphinx-doc.org/en/stable/markup/code.html#directive-literalinclude allows you to have highlighted lines in the example. Which means we can even point out the critical parts
13:34:49 <gmann_> even some microversion change the response completly
13:35:04 <mriedem> gmann_: i think the point is if it's drastic, an example is ok
13:35:11 <sdague> gmann_: this isn't for machines, it's for humans, this is about ensuring you highlight the important change without drowning people in minor issues that make them miss the point
13:35:14 <sdague> mriedem: sure
13:35:35 <sdague> but just adding a couple of parameters to a response, really doesn't need another example in main docs
13:35:43 <mriedem> we also have the rest api version history doc for more detailed prose on each microversion change
13:35:48 <sdague> mriedem: yep
13:36:32 <mriedem> move on?
13:36:37 <sdague> yeh
13:36:53 <alex_xu> for policy discovery
13:36:57 <gmann_> yea, may be we can go case by case there as per content changes
13:37:12 <alex_xu> the spec for CLI merged last week
13:37:30 <alex_xu> #link https://review.openstack.org/289405
13:38:00 <sdague> on the oslo side we're just waiting for https://review.openstack.org/#/c/321243/ to land, and all oslo.policy changes will be in
13:38:15 <alex_xu> yea, just found those landed
13:38:41 <alex_xu> yeah, the last one
13:38:59 <sdague> I've been bugging folks to make sure we move this all forward
13:39:17 <sdague> hopefully we'll get that in this week, and an oslo.policy release
13:39:23 <alex_xu> and i'm going to cleanup the policy rules for legacy v2  api
13:39:25 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:remove_legacy_v2_policy
13:40:21 <alex_xu> the last two patch are https://review.openstack.org/325684 and https://review.openstack.org/#/c/320751/, i probably can make it ready before sleep
13:40:55 <sdague> alex_xu: awesome
13:41:30 <sdague> +A on the bottom 2
13:41:47 <sdague> all these deletes are exciting :)
13:42:06 <alex_xu> then the other legacy v2 cleanup can be running in backaround, nothing urgent.
13:42:13 <alex_xu> sdague: yeah :)
13:42:21 * edleafe like deleting code
13:42:36 <gmann_> alex_xu: sdague will be quick for you, extension setting cleanup in sample tests- https://review.openstack.org/#/c/326810/
13:43:00 <johnthetubaguy> once we are ready of the policy changes, I think the OSIC folks are keen to help with the heavy lifting of moving the defaults into code
13:43:08 <sdague> gmann_: cool, will look after the meeting
13:43:11 <sdague> johnthetubaguy: great
13:43:18 <gmann_> sdague: Thanks
13:43:18 <alex_xu> gmann_: cool!
13:43:21 <sdague> so... are we done with priorities?
13:43:34 <alex_xu> johnthetubaguy: ++
13:43:44 <alex_xu> i guess so
13:43:51 <sdague> because I want to raise a thing about the v2.1 entry points (more for open discussion)
13:43:54 <mriedem> what about api deprecations?
13:44:17 <sdague> mriedem: right... I am still on the hook for a spec on the api deprecations (non proxy)
13:44:24 <sdague> I can probably write that up this week
13:44:34 <mriedem> is code up for the proxy apis?
13:44:36 <sdague> I'm only good with about 1 spec per week on authoring
13:44:38 <sdague> mriedem: nope
13:44:45 <mriedem> sdague: all specs and all code and all reviews all of the time
13:44:47 <mriedem> c'mon
13:45:05 <mriedem> np, was just wondering
13:45:06 <sdague> mriedem: sorry, still working on API #1 priority, which is docs :)
13:45:13 <sdague> and... the glance v2 land
13:45:23 <mriedem> yeah i think technically policy and docs were priority
13:45:31 <sdague> mriedem: yep
13:45:45 <sdague> I'll get the spec up for the deprecations this week
13:46:22 <sdague> the actual code probably won't happen till after midcycle for either, given what my schedule (including vacation) looks like between now and then
13:46:51 <johnthetubaguy> is this something the OSIC folks could help with, I guess the spec will be quite prescriptive?
13:46:57 <sdague> johnthetubaguy: yep, maybe
13:47:18 <sdague> johnthetubaguy: the proxy one is approved
13:47:23 <sdague> you could have them dive there now
13:47:34 <mriedem> i'd caution,
13:47:45 <mriedem> with maybe starting with one api proxy so we're comfortable with the pattern
13:47:49 <mriedem> if the osic people are doing it
13:48:04 <johnthetubaguy> sdague: good point, I will ask
13:48:14 * alex_xu also free for some coding
13:48:22 <johnthetubaguy> mriedem: yeah, a good example to copy would be good
13:48:29 <johnthetubaguy> sounds like alex_xu may have offered to do that bit
13:48:32 <gmann_> i can also help if needed
13:48:54 <johnthetubaguy> gmann_: sounds good
13:48:55 <alex_xu> johnthetubaguy: yeah, i can take a look at
13:49:07 <sdague> ok, alex_xu / gmann_ if you want to start diving on that spec, that would be awesome
13:49:24 <sdague> and help osic folks as they come up to speed
13:49:30 <johnthetubaguy> ++
13:49:32 <gmann_> sdague: sure
13:49:47 <alex_xu> sdague: yeah
13:50:05 <alex_xu> but i'm in vacation next week...
13:50:08 <sdague> ok... are we good on that?
13:50:25 <alex_xu> sdague: yea
13:50:28 <mriedem> yup
13:50:28 <sdague> because I have another item to start people thinking about
13:50:39 <alex_xu> #topic open
13:50:45 <sdague> even though we deprecated and removed all our config options around extensions
13:50:54 <sdague> we still have lots of things as entry points
13:50:56 <sdague> https://github.com/openstack/nova/blob/f10349a60d8fd0c8556b9024e20c2b0349015be4/setup.cfg#L158-L170
13:51:05 <sdague> so people can back door some things
13:51:07 <johnthetubaguy> the stevedoor stuff, good point
13:51:37 <johnthetubaguy> feels like we should be dropping that stuff too?
13:51:42 <sdague> while I think we should get rid of all of that... the thing I really think we need to prioritize getting rid of the the extending existing resources
13:51:53 <johnthetubaguy> ah, the messy bits, yeah
13:51:58 <sdague> because that is super complicated and confusing code
13:52:22 <sdague> and causes bugs like https://review.openstack.org/#/c/315964/2/nova/api/openstack/compute/extended_server_attributes.py
13:52:31 <alex_xu> i guess that is the first step for deprecating extension
13:52:50 <mriedem> is that like adding disk_config to the server response?
13:52:54 <sdague> mriedem: yep
13:53:00 <gmann_> yea
13:53:01 <mriedem> ok
13:53:31 <sdague> mriedem: the point is not to change our responses, but to stop doing that in 8 different decorator hops
13:53:33 <mriedem> mutated dicts via extension listeners is always a great stability pattern
13:53:39 <sdague> mriedem: yeh, exactly
13:53:57 <oomichi_> but if merging all modules into a single place, the code servers.py will become huge and complicated
13:54:05 <sdague> oomichi_: but it will be in one place
13:54:14 <sdague> now it's huge, complicated, and distributed
13:54:14 <mriedem> you can always break each part into private methods
13:54:22 <johnthetubaguy> mriedem: +1
13:54:34 <johnthetubaguy> its better than a single real entity spread between N files
13:54:40 <sdague> johnthetubaguy: ++
13:55:20 <sdague> doing the api-ref docs work really drove home how confusing it is in the current format to even figure out what's in these responses without running all the code
13:55:32 <sdague> and this directly inhibits people contributing
13:55:43 <oomichi_> humm, that seems difficult balance
13:56:07 <mriedem> so, again, maybe we start with normalizing one of these and see the pattern
13:56:12 <mriedem> before getting overwhelmed
13:56:13 <sdague> mriedem: agreed
13:56:19 <oomichi_> and maybe servers.py still continues growing by additional microversions later if merging
13:56:45 <gmann_> seems like main issue is with server.py which becomes too huge
13:56:56 <oomichi_> but yeah, I agree with that new developers will be confused due to current mechanism
13:56:58 <sdague> oomichi_: if servers.py is too big and complicated for use to have it in our tree, the responses over the wire are probably too big and complicated for realize users
13:57:13 <sdague> oomichi_: not just confused, and not just new developers
13:57:19 <gmann_> but i like the mriedem idea to out in private methods
13:57:20 * alex_xu still feel we check microversion deep in the code. the coe become complex
13:57:25 <gmann_> put
13:58:00 <sdague> when mriedem was reviewing some api-ref change I had, we litterly had 2 hours of git links walking through where things were injected magically in resize
13:58:11 <sdague> to prove we were right
13:58:18 <sdague> with people that have worked on the project for 3 years
13:58:20 <johnthetubaguy> right, and we kinda know where to luck
13:58:29 <mriedem> but i'm exceptionally dense
13:58:30 <sdague> it's basically impossible for anyone else to understand this layer
13:58:31 <mriedem> don't forget
13:58:35 <gmann_> sdague: :) truea and SHOW too
13:58:53 <oomichi_> sdague: yeah, nice point
13:59:20 <mriedem> 1 minutes
13:59:23 <mriedem> *minute
13:59:25 <sdague> so, I'll propose some small patches to unwind a thing here and see how it goes
13:59:32 <alex_xu> oops, mriedem thanks
13:59:38 <sdague> but start thinking about the fact that we want to get rid of these entry points
13:59:39 <gmann_> i also spent lot of time to re verify the response schema in tempest
13:59:48 * alex_xu forget the time again
14:00:07 <alex_xu> sorry, let's back to openstack-nova
14:00:10 <alex_xu> #endmeeting