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