14:00:15 <edleafe> #startmeeting nova_scheduler
14:00:16 <openstack> Meeting started Mon Nov 14 14:00:15 2016 UTC and is due to finish in 60 minutes.  The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:20 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:26 <edleafe> Hello! Who's here today?
14:00:26 <macsz> \o
14:01:24 <macsz> well, it seems the room is empty
14:01:47 <alex_xu> o/
14:01:52 * edleafe has room to stretch his legs
14:02:29 <edleafe> Let's wait a little bit for the latecomers
14:03:56 <cdent> o/
14:04:16 <cdent> this is what happens when I show up early, forget to actually show up
14:04:23 <edleafe> heh
14:04:28 <bauzas> holy snap
14:04:30 <bauzas> \o
14:04:44 <bauzas> again, I should departure in 20 mins
14:04:49 <edleafe> bauzas: ack
14:05:03 <bauzas> sadly
14:05:10 <edleafe> As usual, the agenda is here: https://wiki.openstack.org/wiki/Meetings/NovaScheduler
14:05:24 <edleafe> #topic Specs and Reviews
14:05:50 <edleafe> I stole cdent's summary of outstanding things to review, and included in the agenda
14:06:00 <edleafe> Has everyone had a chance to look those over?
14:06:11 <cdent> edleafe: you can't steal what is given freely
14:06:27 <edleafe> Note that today is a Spec Review day, so we should focus on getting the specs done first
14:06:46 <edleafe> cdent: I can and I did!
14:06:50 <cdent> And I left one thing out: https://review.openstack.org/#/c/382640/
14:07:15 <edleafe> #link https://review.openstack.org/#/c/382640/
14:07:58 <edleafe> So... we could go through them one by one, but that doesn't sound very efficient
14:08:36 <edleafe> Instead, does anyone have any issues or problems with any of those specs/reviews?
14:08:47 <cdent> no sir
14:08:47 <johnthetubaguy> quick questions on calling placement
14:08:55 <johnthetubaguy> I was thinking about the caching scheduler
14:09:07 <johnthetubaguy> I assume we just leave that doing what it does today, probably
14:09:27 <johnthetubaguy> basically it works because we get the full list of nodes from the DB
14:09:34 <bauzas> johnthetubaguy: well, given the placement API is still optional, my answer would be yes
14:09:43 <johnthetubaguy> if we don't get the full list, it doesn't really have anything it can cache
14:09:43 <edleafe> johnthetubaguy: I would think so, at least until we can get the placement API to perform better than the caching scheduler
14:09:57 <bauzas> yeah that
14:10:05 <johnthetubaguy> I think we probably need the claims before we can drop it
14:10:13 <cdent> johnthetubaguy: yeah, my recollection was we just wouldn't change the caching scheduler
14:10:17 <edleafe> agreed
14:10:19 <bauzas> you can have operators not wanting to use the placement engine and keep the caching scheduler
14:10:25 <johnthetubaguy> so the caching scheduler is a subclass of the filter scheduler
14:10:38 <johnthetubaguy> is implementation wise, its not as easier as that
14:10:45 <johnthetubaguy> but agreed with the direction there
14:10:50 <johnthetubaguy> its just not noted in the spec
14:10:50 <bauzas> johnthetubaguy: that wouldn't change, the use-filters spec doesn't impact it
14:11:03 <johnthetubaguy> so I am on the wrong spec...
14:11:04 <johnthetubaguy> sorry
14:11:11 <johnthetubaguy> https://review.openstack.org/#/c/300178
14:11:26 <johnthetubaguy> missread the UURL
14:11:29 <bauzas> johnhttps://review.openstack.org/#/c/300178/4 yeah
14:11:55 * johnthetubaguy should get his post lunch coffee quickly
14:12:07 * edleafe needs his morning coffee too
14:12:10 <bauzas> https://review.openstack.org/#/c/385618/1 is a prereq tho
14:12:23 * cdent needs his post coffee coffee
14:12:55 <edleafe> So the point is that we have to allow for an override of the DB filtering for subclasses, right?
14:12:58 * alex_xu just needs to go to bed
14:13:11 <bauzas> edleafe: you mean, other resources ?
14:13:34 <bauzas> edleafe: there are a lot of things in the HostState object that filters use, that are not provided by the current placement resource classes
14:13:42 <johnthetubaguy> I think we could just do a "skip_resource_filters=True" or something
14:14:11 <edleafe> 
14:14:16 <bauzas> feel free to comment on the spec, I'll appreciate ideas for turning off the placement call if needed
14:14:16 <johnthetubaguy> if we are clear on the behaviours, I think the code structure should drop out from that, I just want to see a note about the need to adress it really
14:14:26 <johnthetubaguy> yeah, adding comments right now
14:14:31 <bauzas> edleafe: I agree
14:14:48 <edleafe> johnthetubaguy: yes, but there will have to be something about not removing those filters
14:14:57 <edleafe> johnthetubaguy: the spec talks about deprecating them
14:15:02 <cdent> I think we're describing this backwards
14:15:07 <bauzas> edleafe: http://starecat.com/content/wp-content/uploads/i-love-unicode-mug.jpg
14:15:24 <cdent> the use of the placement api to narrow available resources happens before any filters are every called, it is before entering the filtering loop
14:15:35 <bauzas> edleafe: it's the operator's responsibility to have the flags being consistent
14:15:44 <cdent> so for things like the caching scheduler we need to not do whatever is doing the narrowing, and just call the filtering loop as before
14:15:54 <cdent> s/every/ever/
14:16:01 <bauzas> ie. having the legacy filters being either turned on and placement off, or the legacy being turned off
14:16:10 <jaypipes> edleafe: sorry for being late
14:16:18 <edleafe> cdent: agreed. But we should change the spec to remove the wording about deprecating the filters in that case
14:16:25 <cdent> edleafe: yes
14:16:31 <edleafe> jaypipes: go sit in the corner!
14:16:40 * jaypipes dons duncecap
14:16:48 <bauzas> edleafe: it's all about *deprecating*, not removing
14:16:54 <jaypipes> edleafe: so, a quick update from me...
14:17:10 <edleafe> bauzas: 'deprecating' means 'stop using this thing ASAP'
14:17:26 <jaypipes> edleafe: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/inventory-allocations-ocata
14:17:41 <jaypipes> edleafe:  I rebased and fixed up a few things from that series ^
14:18:02 <bauzas> edleafe: if you use the placement API, those legacy filters should be disabled ASAP, indeed
14:18:07 <jaypipes> edleafe: would appreciate some reviews on that if possible. We should be able to close that out in a day or two unless someone has any major objections.
14:18:15 <edleafe> jaypipes: great. Will review that series
14:18:17 <bauzas> jaypipes: spec review day
14:18:25 <jaypipes> bauzas: ya, I know.
14:18:29 <jaypipes> edleafe: cheers
14:18:45 <bauzas> jaypipes: k., just wanted to make sure you being aware :)
14:18:48 <edleafe> bauzas: What I'm talking about is this sentence: "Legacy filters (CoreFilter, RAMFilter and DiskFilter) that have corresponding
14:18:51 <edleafe> resource classes will be considered deprecated and will be removed in the next
14:18:54 <edleafe> cycle."
14:19:07 <bauzas> edleafe: given my very short time left, can we postpone that discussion ?
14:19:08 <jaypipes> edleafe: on another note, I will be pushing code that adds the Ironic custom resource class handling today.
14:19:20 <edleafe> bauzas: sure
14:19:24 <bauzas> edleafe: just make a comment in the spec, and I'll engage with you
14:19:35 <edleafe> bauzas: do you have a specific topic you'd like to discuss before you go?
14:19:44 <bauzas> edleafe: nothing really
14:19:50 <edleafe> bauzas: ok cool
14:19:57 <jaypipes> edleafe: do we have an etherpad with current highest priority specs to review?
14:20:10 <bauzas> edleafe: well, I won't be able to join next week's meeting
14:20:28 <alex_xu> jaypipes: https://etherpad.openstack.org/p/nova-ocata-spec-review-sprint there is one from Matt
14:20:32 <edleafe> jaypipes: There is the pad that mriedem posted: https://etherpad.openstack.org/p/nova-ocata-spec-review-sprint
14:20:37 <bauzas> jaypipes: cdent amended the priorities etherpad
14:20:52 <edleafe> alex_xu: damn! You're too fast for me! :)
14:20:54 <bauzas> and that, yes
14:21:01 <alex_xu> edleafe: :)
14:21:29 <cdent> bauzas: that was quite a while ago, but yeah. I think the email that I sent, and thus the agenda (since edleafe is a self-confessed thief) is most up to date?
14:22:52 <bauzas> cdent: you mean the priorities etherpad ?
14:22:57 <edleafe> I haven't cross-checked, but if any of our specs aren't on Matt's list, let's be sure to add them
14:23:08 <bauzas> cdent: if so, yes
14:23:19 <cdent> the next time I send that email (presumably friday, I can also update the priority etherpad if that's what people want)
14:24:01 <cdent> edleafe: custom resource classes and nested resource providers were not on matt's etherpad last I checked but I didn't add things because I thought I recalled matt saying he didn't want people to do that (but since then people have)
14:24:29 <edleafe> didn't want people to add specs to the etherpad? Or just those specs?
14:25:17 <cdent> didn't want people to add things, but I'm probably misremembering, or conflating something with the wrong thing
14:25:23 <bauzas> folks, \o
14:25:26 <cdent> but given the bubble has burst we should add
14:25:30 <bauzas> time is flying
14:25:32 <johnthetubaguy> you are right cdent, he said ask him for adds
14:25:36 * bauzas runs errand
14:25:58 * cdent is relieved, not yet totally brain dead
14:26:46 <edleafe> OK, we ask for Matt's blessing on any specs we need reviewed
14:27:37 <edleafe> #action edleafe to ask mriedem to add any placement specs to the review etherpad
14:27:43 <edleafe> I'll take that one
14:28:29 <edleafe> Anything else to discuss for specs/reviews?
14:28:53 <johnthetubaguy> did we want to cover
14:28:56 <johnthetubaguy> POST vs GET?
14:29:26 <edleafe> I'd rather cover tabs vs. spaces :)
14:29:45 <cdent> johnthetubaguy: we were going to do that on the spec and poc, I think
14:30:05 <johnthetubaguy> OK, cool
14:30:31 <edleafe> Let's move on
14:30:36 <edleafe> #topic Open Discussion
14:30:50 <edleafe> First up: Ocata Upgrade Plans
14:31:27 <edleafe> We aren't clear on just what steps operators will have to take as the placement API is rolled out
14:31:34 <cdent> matt r wrote some useful stuff about that in response to my email
14:31:48 <edleafe> cdent: yes, I saw that
14:32:00 <cdent> and also in his (excellent) start on the docs
14:32:15 <edleafe> So I guess we need to officialize the upgrade steps
14:32:55 <edleafe> Since bauzas isn't here, let's assign it to him!!
14:32:59 <edleafe> (jk)
14:33:41 <edleafe> So should we build on Matt's response?
14:34:21 <cdent> seems like a reasonable plan
14:34:35 <edleafe> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/107177.html
14:34:44 <edleafe> ^^ Matt's response
14:36:23 <cdent> this has two +2 but no +W can somebody kick it in, unless there are objections: https://review.openstack.org/#/c/395971/
14:37:27 <johnthetubaguy> hmm, I didn't +W, thats odd
14:37:48 <johnthetubaguy> ah, I was kinda waiting for dan to respond
14:38:10 <edleafe> johnthetubaguy: so can you follow with dan about that?
14:38:55 <johnthetubaguy> yeah, its my bad for not adding that in my vote
14:39:25 <edleafe> johnthetubaguy: thanks
14:39:38 <edleafe> Next up: documentation
14:39:52 <edleafe> mriedem already gave us an excellent start: https://review.openstack.org/#/c/396761/
14:40:39 <edleafe> I see a TODO for api-ref. That can get started while we settle more bits in the API
14:41:17 <edleafe> Any comments / suggestions?
14:41:18 <cdent> one of the open questions on that is how to source some of the info for the api-ref, as I guess in compute-api the api-samples are used for that
14:41:53 <cdent> we can probably figure out a way to use the gabbits but it may not be worth the effort: the api is pretty simple and hopefully will stay that way
14:41:58 <cdent> (we should fight hard to keep it that way)
14:42:11 <edleafe> alex_xu: any ideas of this? (If you're still awake :)
14:42:31 <edleafe> cdent: +1 on not mucking up the API
14:42:59 <alex_xu> edleafe: agree with cdent, the api is pretty simple, so it is ok without some automatically
14:43:57 <edleafe> alex_xu: ok, good to know
14:44:13 <edleafe> Anything else to discuss for Opens?
14:44:19 <alex_xu> actually the api-ref of compute isn't generated from anything also. only the api sample files are generated from api sample tests. and add refer link to the api-ref
14:47:29 <edleafe> Looks like we're done.
14:47:33 <edleafe> Thanks everyone!
14:47:36 <edleafe> #endmeeting