13:00:04 <alex_xu> #startmeeting nova api
13:00:04 <openstack> Meeting started Wed Apr 13 13:00:04 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:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:07 <openstack> The meeting name has been set to 'nova_api'
13:00:13 <alex_xu> who is here today?
13:00:24 <cdent> o/
13:00:26 <jichen> o/
13:00:59 <gmann_> hi
13:01:04 <edleafe> \o
13:01:11 <sdague> o/
13:01:27 <alaski> o/
13:01:32 <alex_xu> good morning and evening for everyone!
13:01:39 <claudiub|2> o/
13:01:43 <alex_xu> let's start the meeting
13:01:56 <alex_xu> alaski, claudiub|2 welcome
13:02:04 <alaski> thanks
13:02:16 <alex_xu> #topic API Priorities
13:02:44 <alex_xu> let's talk about api doc first
13:02:51 <alex_xu> sdague: your turn
13:03:00 <sdague> alex_xu: ok
13:03:23 <sdague> I think we are about as good as we are going to get on automated translation
13:03:35 <sdague> https://review.openstack.org/#/c/302500/9
13:03:45 <sdague> is the current top of stack for that
13:03:59 <sdague> it's now 1 rst file per "group"
13:04:04 <sdague> and a single parameters file
13:04:24 <alex_xu> sdague: does those patch ready for review, or still under some debug?
13:05:03 <sdague> there is plenty that is going to need to get cleaned up from here, but I think that's probably as close as we're going to get (more work on the translators are probably not going to really going to be faster than just fixing in place)
13:05:07 <sdague> alex_xu: yes, I think so
13:05:16 <gmann_> that's more allinged with sample files. each per group
13:05:38 <sdague> I think the only real question is if the single parameters file and the rst files grouped like that is conceptually good for folks
13:05:58 <sdague> http://docs-draft.openstack.org/00/302500/9/check/gate-nova-api-ref/81d644c//api-ref/build/html/ is the output that generates
13:06:25 <sdague> after that point, it's going to be building a scrubbing list and going through the docs and fixing all the issues that are there
13:06:32 <sdague> some which are translation issues
13:06:50 <sdague> some of which are just issues that have always been in the content
13:07:08 <sdague> so, I guess, that's question #1
13:07:24 <sdague> does the 1 parameters file & rst per group look good to folks?
13:07:35 <alex_xu> is the grouped file good for support microversion?
13:07:44 <gmann_> sdague: we are going to dump sample files there as request response example right
13:07:48 <sdague> question #2 - what is the best way to build out the todo to scrub it
13:08:03 <sdague> gmann_: I'm not sure I understand the question
13:08:42 <gmann_> sdague: I mean we have sample files also in same group structure. so are we going to add their content in doc for request example and response example
13:08:52 <sdague> gmann_: they are
13:08:58 <sdague> by reference
13:09:14 <sdague> http://docs-draft.openstack.org/00/302500/9/check/gate-nova-api-ref/81d644c//api-ref/build/html/#create-server
13:10:10 <gmann_> sdague: oh, cool, that's nice
13:10:52 <sdague> alex_xu: I think that the groups are probably fine for microversions, we kind of need to clean up what's here first before we can start doing that part
13:12:08 <alex_xu> sdague: ok, but i will try keep this question when review the patch
13:12:21 <sdague> sure
13:12:29 <gmann_> yea, selection of microversion in drop down and results to only group which got changed there will be nice
13:13:11 <alex_xu> sdague: for the todo, probably just let people take each group, then go to fix the problem in each group, as the way we doing similar works
13:13:31 <gmann_> sdague: their content need more structured way right? like Preconditions, Troubleshooting etc all in plain text now.
13:13:49 <sdague> gmann_: yeh, that's one of those things that is going to have to be fixed manually
13:13:59 <gmann_> sdague: i see,
13:14:16 <gmann_> alex_xu: +1 for taking group by group
13:14:26 <sdague> alex_xu: sure, we can etherpad it, or we can make some bugs on it
13:15:03 <sdague> that was basically my question, if launchpad bugs might be more useful as the todo list because it's easier to know someone is doing it and what isn't done yet
13:15:10 <alex_xu> sdague: at least we have one sample to talk people which is the finally thing looks like?
13:15:20 <alex_xu> s/talk/tell/
13:15:44 <sdague> alex_xu: right, there is something to show now.
13:16:11 <gmann_> sdague: LP bug for each group updates?
13:16:12 <alex_xu> sdague: one good thing is launchpad have more visible, maybe get more help from people outside nova api team
13:16:36 <sdague> anyway, we should decide if this format is good enough to land soon, so then we can switch focus from the converter to manually fixin
13:16:50 <sdague> because it's a waste of time to start manually fixing if we are going to regenerate the base files
13:16:59 <edleafe> sdague: looks great to me
13:17:11 <alex_xu> sdague: the 'todo' point to some kind of improvement for the doc structure and html page style, or just the content?
13:18:04 <sdague> alex_xu: I think it's kind of as follows:
13:18:04 <alex_xu> sdague: ok, so review those pach first
13:18:13 <sdague> 1) land base conversions
13:18:58 <sdague> 2) audit for missing methods (like GET /server/details)
13:19:17 * alex_xu must have network latence
13:19:21 <sdague> 3) fix missing parameters list
13:19:26 <sdague> (no I'm typing slow)
13:19:59 <sdague> 3) fix parameters lists for each group (fix wrong references, double check for missing parameters, add microversion parameters)
13:20:32 <sdague> 4) fix body text in each group for formatting issues
13:20:52 <alex_xu> okay...huge number of works...
13:20:54 <sdague> 5) reorder methods into logical groupings
13:21:00 <sdague> yeh, there are lots of things to be done
13:21:03 <gmann_> sdague: 3) ..add microversion parameters ?
13:21:07 <sdague> I can build the full scrub list
13:21:40 <sdague> gmann_: there is support in the parameters file for microversion adds of parameters
13:21:44 <gmann_> sdague: list vise items will help and we apply those in for loop for all group
13:21:50 <sdague> but that all has to be added
13:22:26 <alex_xu> if each problem for one launchpad bug, must pain. If just 'fix missing parameters list' as a bug, then looks like useless. :(
13:22:49 <sdague> alex_xu: right, I agree, we're going to need to handle this with more specifics
13:23:11 <sdague> so it's kind of each phase per file, maybe I'll figure out if there is a good way to automate building those bugs
13:23:42 <alex_xu> sounds cool
13:24:01 <sdague> let me write out in english all the things I think we need to do in an email today, then we can figure out tracking of it
13:24:35 <alex_xu> sdague: cool, then probably people can help on you
13:24:39 <gmann_> +1
13:24:41 <sdague> yep
13:24:53 <alex_xu> ok, so let move on?
13:25:36 <sdague> yes
13:26:12 <alex_xu> ok, let jump to policy discover
13:26:26 <alex_xu> alaski, claudiub|2 do you have any update?
13:26:37 <alex_xu> claudiub|2: have conflict meeting with hyperv
13:27:12 <alaski> on my side I'm mostly focused on the low level changes required for olso.policy to provide what is needed to build this
13:27:33 <sdague> https://review.openstack.org/#/c/290155/ looks pretty solid, we should probably get folks to land that one
13:27:53 <alaski> basically just to get to the point of answering the question, "can this context pass these policy checks"
13:27:55 <sdague> I need to rereview the API version
13:28:13 <alex_xu> yea, already +1 by most of api team members
13:28:33 <sdague> alaski: ok, cool. Is that a thing that you are actively working? or is that a thing you need / want help on
13:28:34 <alaski> the question I have now is do we want to expose this simple offering in the API, or build grouping on top first
13:29:07 <alaski> sdague: I plan to actively work the olso.policy changes, but not the actual registration of policy
13:29:11 <alaski> I could use help on that part
13:29:16 <sdague> my feeling is we should start with the simple thing over the API
13:29:28 * gmann_ put this in review list for tomorrow
13:29:48 <claudiub|2> can you explain what those simple things are?
13:30:13 <alex_xu> I submitted a spec which I separated from policy discover api, it is about remove the target parameter from enforce method: https://review.openstack.org/#/c/305026/
13:30:13 <sdague> claudiub|2: making the payload be basically just the policy.json lines as are
13:30:25 <alaski> right, just a list of policies you pass
13:30:35 <claudiub|2> so, basically, the original proposal of the spec. ok
13:30:36 <alex_xu> if we remove the target parameter, we probably can enforce policy from framework layer maybe
13:30:48 <alaski> there's still a wrinkle in there which is the target parameter
13:30:57 <alaski> some policies depend on the resource being acted upon
13:31:26 <alex_xu> if no target parameter, then we probably just do something in the top
13:31:49 <alaski> that could work
13:32:01 <alaski> I'm not sure about removing the target parameter though
13:32:11 <claudiub|2> yeah, that's true. someone suggested that we could have something like /servers/id/policy, and return a set of policy rules / actions based on that target.
13:32:18 <alaski> that was me :)
13:32:35 <alex_xu> alaski: yes, that is way I submitted a spec for that, I think that is good for discuss this problem.
13:32:39 <sdague> lets figure out what happens after we move policy enforcement into a context method call
13:32:41 <alex_xu> s/way/why/
13:32:54 <alaski> I was thinking that we actually have two classes of policies, general actions and then actions under a target
13:33:00 <sdague> because it sounds like the real issue is that a lot of times the target is faked
13:33:36 <alaski> I don't think it is
13:33:49 <alaski> but I'm happy to defer until we have some of this work done
13:33:56 <alex_xu> sdague: if it isn't faked, it still doesn't work due to the db always filter by project_id for non admin user
13:34:42 <alaski> alex_xu: I haven't seen your spec, can you link me or add me to it?
13:34:44 <sdague> yeh, let's get the base patches done first
13:34:58 <alex_xu> #link https://review.openstack.org/#/c/305026/1
13:35:00 <alex_xu> alaski: ^
13:35:03 <alaski> thanks
13:35:10 <sdague> alex_xu: I think that your spec might change after alaski's base infrastructure parts are in place
13:36:33 <alex_xu> sdague: yes, that is can be. We can refactor if we find way we needn't put context.can() in each api each.
13:36:48 <alex_xu> when we decide without target is right thing
13:36:49 <sdague> right, so lets focus on alaski's spec
13:36:55 <alaski> food for thought, but we may want to split policy to answer two questions. Can I do this, like resize for example, and then can I do this on this particular resource
13:36:55 <sdague> and the code to implement it
13:37:01 <alex_xu> sdague: cool, +1
13:37:33 <alaski> with a split we could do one level of enforcement in the api framework, and then the second level where appropriate
13:37:53 <alaski> but that should be discussed later
13:38:26 <alex_xu> emm...really good food for thought
13:38:49 <claudiub|2> yeah, we can do that
13:39:50 <alaski> so that's my update. I'll be working on getting the framework in place, but could use help registering all of the policies when that is done
13:40:05 <sdague> alaski: ok, cool, is there a rough ETA on framework?
13:40:07 <claudiub|2> I can help with that
13:40:08 <alex_xu> alaski: cool
13:40:28 <gmann_> alaski: +1
13:40:30 <sdague> because we can't really divide and conquer the policy registration until that's there
13:40:30 <alex_xu> may i ask what is ETA?
13:40:40 <alaski> sdague: I wasn't pushing too hard until after the summit discussion, but shouldn't take too long after that
13:40:40 <sdague> estimated time of arrival
13:40:47 <sdague> alaski: ok great
13:41:00 <sdague> yeh, everyone should be prepared for these discussions at summit
13:41:01 <alex_xu> sdague: thanks
13:41:08 <sdague> there will be a cross project session on tuesday
13:41:24 <sdague> and this will be the focus of the nova API discussions on thursday
13:42:44 <claudiub|2> cool. just one question from me: so basically the policy nova-api endpoint will just return the list of passing policies, right?
13:42:56 <sdague> claudiub|2: yes, I think so
13:42:57 * alex_xu need prepare to listen more english listening classs....
13:43:29 <claudiub|2> and also, listing the available endpoints to the user based on his policies, will that still be a good feature to have?
13:43:31 * oomichi_ same as alex
13:43:32 <alex_xu> ok, sounds cool at here
13:44:18 <alaski> claudiub|2: I think the goal is to move in that direction, but what it actually looks like will probably have a lot of discussion
13:44:42 <alex_xu> i guess so also
13:45:12 <claudiub|2> well, sounds good to me. listing all the endpoints correctly at the moment is quite challenging at the moment, to be honest.
13:45:28 <claudiub|2> and all the correct details / bodies.
13:45:43 <claudiub|2> especially since some policy rules do not match the action name. :)
13:45:51 <alaski> yeah, we'll need to build this up one step at a time to enable that
13:46:08 <sdague> claudiub|2: right, but aliasing all that is phase 2 or 3
13:46:15 <sdague> lets just get this in code, and exposed over the wire
13:46:23 <sdague> and get that whole flow working
13:46:32 <claudiub|2> cool.
13:46:33 <sdague> then we can start working on better UX for the whole thing
13:46:56 <sdague> I think we'll learn a lot by the time we get there as well, which will help inform the UX conversation
13:47:10 <alaski> agreed
13:47:25 <claudiub|2> i suppose we also need a blueprint for the renaming / aliasing.
13:47:44 <claudiub|2> anyways, lgtm.
13:47:53 <alaski> we will, yes
13:48:35 <alex_xu> ok, cool, sounds we can move on?
13:48:52 <claudiub|2> agreed.
13:49:07 <alex_xu> #topic Nova Microversion testing in Tempest
13:49:10 <alex_xu> gmann_: your turn
13:49:23 <gmann_> alex_xu: not much on this.
13:49:33 <gmann_> alex_xu: did not get much chance to work on this last week.
13:49:47 <alex_xu> gmann_: ok, no problem, we already very good on this
13:49:52 <gmann_> most probably i will continue on this after summit.
13:50:13 <alex_xu> gmann_: ok, sounds cool, thanks for working on this
13:50:19 <gmann_> np!
13:50:28 <alex_xu> so just let's move to open
13:50:30 <alex_xu> #topic open
13:50:40 <alex_xu> modern microversion, when and how do we want 'em - https://review.openstack.org/#/c/300077/
13:50:46 <cdent> yeah, that was me
13:50:52 <alex_xu> cdent: yea, go ahead
13:51:08 <cdent> Essentially: do we want to do this and when. If so, what are the testing constraints.
13:51:33 <cdent> I'm not in any rush, but it will need some coordination and specification, so I just want to get a measure of interest and desire
13:52:23 <alex_xu> anytime, just not priority item i guess, and the patch isn't huge, looks like pretty good land it in newton
13:52:55 <cdent> I assume it would require a microversion itself, and thus a spec, or just a blueprint?
13:53:31 <gmann_> cdent: alex_xu just had first look there, do we need to return both header in response or the one which was requested
13:53:42 <alaski> typically a microversion bump requires a spec
13:53:45 <alex_xu> emm...use a microversion to discover another microversion header
13:53:47 <sdague> cdent: all microversions have a spec
13:53:52 <sdague> it should be quick
13:54:00 <gmann_> cdent: IMO microversion need to publish the new header support at least
13:54:07 <alex_xu> gmann_: yes, i think so
13:54:07 <gmann_> yea
13:54:10 <sdague> alex_xu: we need to document that after some point this header is accepted
13:54:18 <sdague> kind of like the project_id optionality
13:54:35 <sdague> cdent: I'd like to get that in during Milestone 1 just to make things more standard
13:54:48 <cdent> Okay, I can cook the spec soon.
13:54:52 <sdague> cdent: so if you could throw up a quick spec, we should be able to move it through soon
13:54:59 <sdague> it should be really straight forward
13:55:00 <cdent> #action: cdent make new microversion header spec
13:55:10 <alex_xu> sdague: emm...yes, that is right, clear now
13:55:29 <alex_xu> cdent: thanks
13:55:30 <cdent> as stated on that review I'm a bit concerned/confused on how to proceed with testing
13:55:47 <cdent> but we can work that when proper reviewing happens, I guess
13:56:12 <cdent> the other open item was also me: https://review.openstack.org/#/c/304958/
13:57:07 <cdent> and has similar questions, changing a 400 to a 415 requires a microversion, thus a spec. someone from an internship program somewhere jumped on that bug very quickly and is now confused by the bureaucracy they have to traverse to get it merged. he and I are going to work together on that
13:57:09 <alex_xu> emm...if someone use wrong content-type, must be a program mistake, as nova only support json
13:57:26 <cdent> alex_xu: we wish to support a diversity of clients
13:57:31 <cdent> what those clients do is unknown to us
13:57:40 <cdent> so if they send a bad request we should send the correct response code
13:57:41 <cdent> yes?
13:58:02 <cdent> the content-type in the POST request, not response
13:58:49 <alex_xu> cdent: yes, i'm just think, maybe this needn't microversion, as is there anyone write code like "if 415 then...."
13:58:56 <alex_xu> ?
13:59:16 <alex_xu> so if no, sounds like a status code change for this won't effect the clients
13:59:41 <alex_xu> omg, 1 mins left
13:59:48 <alex_xu> let move back to openstack-nova?
13:59:51 <cdent> I have written client code in the past that interprets 4xx responses to provide options on how to proceed
13:59:57 <sdague> my inclination on this one is to say this was a bug and should be fixed and backported
14:00:01 * cdent nods
14:00:02 <sdague> because it was screwed up
14:00:07 <alex_xu> #endmeeting