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