13:00:16 <alex_xu> #startmeeting nova api 13:00:17 <openstack> Meeting started Wed Mar 8 13:00:16 2017 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:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:20 <openstack> The meeting name has been set to 'nova_api' 13:00:21 <cdent> o/ 13:00:26 <alex_xu> who is here today? 13:00:31 <gmann> o/ 13:00:43 <Kevin_Zheng> o/ 13:01:17 <alex_xu> #topic policy improvement 13:01:36 <alex_xu> johnthetubaguy: are you around, do you have anything want to talk about policy? 13:02:27 <alex_xu> #link https://review.openstack.org/433010 13:02:45 <alex_xu> the doc one I guess just need to update, I feel it should be very easy one 13:02:56 <alex_xu> #link https://review.openstack.org/433037 13:03:05 <gmann> yea 13:03:17 <alex_xu> ^ the scope check one, I added two comments. 13:03:48 <alex_xu> one is dump my thinking about is there anything related to capabilities API with scope check 13:03:57 <alex_xu> I feel it should be good 13:04:29 <alex_xu> another one is I feel 'scope' mix the scope definition and target together, that may make people confuse 13:05:42 <gmann> alex_xu: you mean scope on discovery policy right 13:05:54 <alex_xu> gmann: yea 13:07:46 <gmann> yea from capability discovery pov, it will be nice 13:07:54 <alex_xu> looks like nothing will expose on the capabilites API about scope 13:09:05 <alex_xu> anyway johnthetubaguy isn't here, looks like we didn't have too much can talk 13:10:51 <alex_xu> #topic open 13:11:02 <alex_xu> anything people aware, or want to bring up? 13:11:24 <cdent> I'd just like to mention/remind people to look at the api stability guidelines: https://review.openstack.org/#/c/421846/ 13:11:45 <cdent> nova pretty much follows or even defined all those, but it is worth reviewing them 13:12:19 <gmann> cdent: thanks for reminder. ll re look tomorrow. 13:12:25 <alex_xu> cdent: thanks, add it to my list 13:13:35 <alex_xu> cdent: what happened to capabilities API https://review.openstack.org/#/c/386555/, looks like no progress after PTG 13:14:22 <cdent> alex_xu: it was decided that for the time being nova would explore putting a small number of capabilities, just to satisfy the horizon use case, in the server instance data 13:15:09 <alex_xu> cdent: ah, thanks 13:15:30 <alex_xu> I didn't see any news from the nova side also :) 13:15:47 <robcresswell> cdent: Was anyone from Horizon in that session? I couldnt attend because I was running Horizon at the same time 13:16:26 <cdent> robcresswell: not that I was aware. I wasn't really driving the capabilities discussion 13:16:36 <robcresswell> (I think, unless I just flat out missed it) 13:16:44 <robcresswell> Okay, fair enough. 13:17:03 <robcresswell> Capabilities on list, rather than details, would be much more useful for us really :/ 13:17:23 <robcresswell> anyway, sorry to derail your meeting, I just saw the Horizon ping :) 13:17:34 <cdent> I think the idea was basically to do what it takes to make horizon happy 13:17:38 <alex_xu> no worries :) 13:18:06 <cdent> johnthetubaguy and sdague were driving the conversation 13:18:53 <robcresswell> Well, our ideal solution would be to return a list of some sort per instance on an instance list. So you'd get something like {id: "foo", name: "bar", capabilities: ["lock", "soft reboot"]} 13:19:25 <cdent> robcresswell: yeah, I think that's kind of the idea 13:19:41 <cdent> a new field, capabilities, that had the magic sauce in it 13:19:50 <robcresswell> That way our tables can just show the relevant actions, and nova will let us know what it can and cant do 13:20:02 <robcresswell> Cool, the key bit is being able to access that on a list call, thats all :) 13:20:18 <gmann> and it will change at run time i mean depend on instance state operation etc 13:21:35 <alex_xu> what is the id and name? 13:21:52 <cdent> alex_xu: that's instance info 13:22:36 <alex_xu> cdent: ok, the uuid of instance, and the name of instance? 13:23:04 <robcresswell> yeah sorry, was just attempting to give some context for structure without having the api handy 13:24:15 <gmann> robcresswell: cdent how horizon will fetch the dynamic changed capabilities ? some notification or periodic refresh ? 13:25:10 <robcresswell> gmann: I'm less concerned about rechecking that information. I don't think its likely to change quite that quickly. 13:25:19 <robcresswell> Just getting it in the first place would be nice 13:26:24 <gmann> but that will change depends on instance state, like capabilities on active server vs paused server 13:26:37 <alex_xu> i guess at least part of state change of instance is trigger by the button of horizon 13:26:59 <robcresswell> Right, but most of the time Horizons current design does full page refreshes anyway 13:27:14 <gmann> ok 13:28:19 <alex_xu> robcresswell: cdent thanks for the info 13:28:40 <robcresswell> alex_xu: No problem, if I can help with anything else please ping me 13:28:49 <alex_xu> robcresswell: thanks! 13:28:53 <robcresswell> And again, sorry for hopping in like that :) 13:29:14 <alex_xu> robcresswell: no worries, we have a lot of free time for today meeting :) 13:29:29 <alex_xu> anything more people want to bring up? 13:29:34 <gmann> alex_xu: i saw some of the view builder patches like - hypervisor, keypair etc 13:29:40 <gmann> #link https://review.openstack.org/#/c/335282/19 13:30:08 <gmann> any objection on those kind of changes ? i think they will be helpful for api extension merge 13:30:26 * johnthetubaguy only just realises its wednesday 13:30:34 <alex_xu> gmann: why that will help for api extension merge? 13:31:11 <gmann> alex_xu: on extension merge, it will be helpful to have readable code on controller side and separate the view buidling on view side 13:31:29 <gmann> hypervisor and keypair are not good example on that 13:31:30 <alex_xu> johnthetubaguy: i guess you very enjoy the work everyday, and forget the date :) 13:32:02 <johnthetubaguy> alex_xu: well take full hour for lunch to practice my tuba for a contest coming up, but similar :) 13:32:15 <johnthetubaguy> gmann: looks like two changes in there 13:32:25 <johnthetubaguy> there is a lot of stuff moved into the view? 13:32:42 <johnthetubaguy> I find that really hard to review 13:32:48 <gmann> yea, response object building one 13:33:08 <johnthetubaguy> try move everything into the hypervisors main class, and no move into the view builder 13:33:17 <johnthetubaguy> I think it would be easier to review that 13:33:55 <gmann> humm, hope that does not make class very large 13:33:58 <johnthetubaguy> thats fine 13:34:04 <alex_xu> The API layer already very thin 13:34:04 <johnthetubaguy> a second patch can split it up if needed 13:34:15 <johnthetubaguy> its just doing that in one patch makes is *really* hard to see whats happening 13:34:39 <johnthetubaguy> I was expecting to see extensions being delete, why is that not happening here? 13:35:02 <gmann> +1 on separating the patch. 13:35:21 <johnthetubaguy> oh, so this isn't removing an extension I guess? 13:35:24 <gmann> but putting response object buidling on view side should be ok right? 13:35:37 <johnthetubaguy> hmm, I am not sure that was a good idea really 13:35:49 <gmann> johnthetubaguy: yea no extension removal there seems. 13:36:26 <gmann> i will try if i can put some time on extension merge which will give more clarity on code refactoring if needed 13:37:00 <johnthetubaguy> robcresswell: alex_xu: cdent: on capabilities, I think tonyb is writing that up post PTG, but... the requirements issues distracted him last week 13:37:21 <johnthetubaguy> I don't think the aim here should be small files 13:37:28 <johnthetubaguy> the aim should be easy to read and maintain code 13:37:52 <johnthetubaguy> so the extensions that split one bit of logic into three files for no good reason anymore, totally pull them into one file 13:38:11 <johnthetubaguy> I would actually prefer patches that delete all the view builders 13:38:16 <robcresswell> johnthetubaguy: Yeah, I spoke to him at the PTG about what would be ideal for Horizon. I imagine there'll be a bit of compromise anyway, as I'm not aware of the perf implications on the Nova side. 13:38:16 <alex_xu> gmann: do you need a bp for extension merge? 13:38:29 <gmann> alex_xu: we have already. 13:38:33 <johnthetubaguy> robcresswell: yeah, he totally missunderstood the Nova conversation it turns out 13:38:45 <johnthetubaguy> robcresswell: what you suggested is more where the Nova side was landing, I think 13:38:46 <gmann> johnthetubaguy: :) deleting all will be hard mainly for server 13:38:46 <alex_xu> I'm also not on the view builders side 13:38:49 <robcresswell> johnthetubaguy: lol, *facepalm* 13:38:57 <robcresswell> johnthetubaguy: Awesome, thats good to know 13:39:28 <johnthetubaguy> robcresswell: yeah, luckily he told me while I was eating a really nice burger sat next to alex_xu, so I was in a good mood, lol 13:39:53 <johnthetubaguy> sorry, I was late, wanted to set that bit straight 13:40:10 <johnthetubaguy> gmann: why is it hard? lots of work for sure 13:40:55 <johnthetubaguy> gmann: different actions in different files is manageable, its the adding attributes to existing API call in a separate file we should focus on, I think. 13:42:07 <gmann> yea that is we will fix, having all appending bits together 13:42:19 <johnthetubaguy> yeah, fixing that would be great 13:42:25 <johnthetubaguy> making adding new stuff way easier 13:42:44 <johnthetubaguy> the other bits, and the view split, I think we should just leave till we have those nasty bits sorted 13:42:50 <alex_xu> or maybe we should get rid of the stevedore first, than begin to that a lot of merge work 13:43:01 <gmann> anyways we can iterate view building things later once all extensions are in single place. 13:43:05 <gmann> johnthetubaguy: +1 13:43:06 <johnthetubaguy> we know it worked when we delete loads of that boiler place extension code 13:43:34 <johnthetubaguy> alex_xu: yeah, dropping stevedore is probably a good step 13:43:43 <gmann> yea 13:43:46 <johnthetubaguy> good first step 13:44:19 <johnthetubaguy> so (1) drop stevedore (2) drop extensions that just add attributes into existing actions (3) have a nap 13:45:02 <alex_xu> at least merge extension won't be a blocker 13:45:11 <gmann> +1 :) like 3rd one 13:45:18 <alex_xu> :) 13:46:07 <alex_xu> I may take a look at if i have any idea about drop stevedore without a lot of work 13:46:42 <johnthetubaguy> I think we can go back to a static list of classes in the API stuff that used stevedore before 13:47:00 * johnthetubaguy waves hands 13:47:10 <alex_xu> yea, calling the current extension point static 13:47:49 <johnthetubaguy> frankly its tempting to migrate to use the placement API stack at somepoint, but thats a different discussion 13:48:16 <alex_xu> yea, placement API stack is very simple and clear 13:48:17 <johnthetubaguy> i.e. straight forward static routing of URLs to functions 13:48:44 <johnthetubaguy> but thats quite a big patch, something for later 13:48:52 <alex_xu> johnthetubaguy: ++ 13:49:05 <gmann> yea that's nice for long term 13:49:06 <johnthetubaguy> but once we get rid of the multi-extensions stuff, it should be a simple-ish switch over 13:49:21 <johnthetubaguy> i.e. one function for each API 13:49:33 <johnthetubaguy> (expect for the version dispatch, thats fine) 13:50:16 <johnthetubaguy> its all built to solve a problem we no longer have, but anyways 13:50:35 <cdent> johnthetubaguy: placement has version dispatch too 13:51:09 * alex_xu begin to image a lot of things 13:51:13 <johnthetubaguy> cdent: totally 13:51:30 * cdent considers quoting this entire section to his CV ;) 13:51:44 <johnthetubaguy> cdent: heh, actually a good idea 13:51:45 <alex_xu> heh 13:51:49 <gmann> :) 13:52:26 <alex_xu> #link https://etherpad.openstack.org/p/pike-nova-priorities-tracking 13:52:50 <alex_xu> I see there still a section for api-team, although there isn't priorities task in the api team 13:53:05 <johnthetubaguy> policy stuff was priority I thought 13:53:07 <johnthetubaguy> the docs 13:53:18 <alex_xu> or it is for tracking the thing api-team awared 13:53:28 <alex_xu> johnthetubaguy: ok 13:54:13 <alex_xu> #action alex to update the priorities tracking etherpad 13:54:34 <gmann> nice, it will help 13:55:25 <johnthetubaguy> sneti and aunnam are working on the policy docs with me 13:55:31 <alex_xu> 5 mins left, please bring up anything want to talk about soon 13:55:35 <alex_xu> johnthetubaguy: cool 13:55:42 <johnthetubaguy> so most patches are likely to come with them 13:55:45 <johnthetubaguy> #link https://review.openstack.org/433010 13:55:55 <johnthetubaguy> so I think I just updated with the comments mentioned earlier in the meeting 13:56:08 <johnthetubaguy> alex_xu: did I get the two URLs correct in there? 13:56:44 <johnthetubaguy> line 65 13:57:06 <alex_xu> johnthetubaguy: yea, that is the case 13:57:20 <alex_xu> johnthetubaguy: but is there anyway to point the specific field clearly? 13:57:32 <alex_xu> i guess the hostname field should have some prefix? 13:57:45 <johnthetubaguy> there isn't, but I think thats OK for now 13:57:52 <johnthetubaguy> its about making small steps forward 13:57:53 <alex_xu> the hostname is talked in the title 13:58:04 <johnthetubaguy> the description will tell the human what the attribute is (or it should) 13:58:24 <alex_xu> johnthetubaguy: ok, that also works 13:58:43 <alex_xu> johnthetubaguy: it is really good start 13:58:56 <johnthetubaguy> yeah, lets iterate on this 13:59:04 <johnthetubaguy> just looking at your scope comments 13:59:07 <johnthetubaguy> context.check_scope(scope={"project_id": "%{project_id}s"}, target=instance) 13:59:08 <alex_xu> append more thing later will be more easy 13:59:14 <johnthetubaguy> conext.check_scope(scope=PROJECT_SCOPE, target=instance) 13:59:23 <alex_xu> johnthetubaguy: 1 mins left.... 13:59:35 <johnthetubaguy> yeah, I am tempted to leave those details for the code review 13:59:39 <johnthetubaguy> the spec should just be the direction 13:59:53 <alex_xu> johnthetubaguy: ok 13:59:58 <alex_xu> i'm cool with that 14:00:01 <johnthetubaguy> I will think on your idea though, I was thinking of: 14:00:10 <alex_xu> #endmeeting