14:00:18 <edleafe> #startmeeting nova_scheduler
14:00:19 <openstack> Meeting started Mon Feb 13 14:00:18 2017 UTC and is due to finish in 60 minutes.  The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:25 <cdent> o/
14:00:26 <macsz> \o
14:00:28 <jroll> morning
14:00:33 <edleafe> Good UGT morning, all!
14:01:22 <jaypipes> o/
14:01:48 <diga> o/
14:02:27 <edleafe> Should be a rather quick meeting today, as there isn't anything on the agenda!
14:02:30 <edleafe> :)
14:02:37 <edleafe> #topic Specs and Reviews
14:03:00 <edleafe> Even though they weren't on the agenda, I wanted to point out a few:
14:03:05 * bauzas waves
14:03:07 <edleafe> Traits spec:
14:03:08 <edleafe> #link https://review.openstack.org/#/c/345138/
14:03:27 <edleafe> Traits POC series, starting with:
14:03:28 <edleafe> #link https://review.openstack.org/#/c/377381/
14:03:46 <edleafe> Now that Pike is open, let's get some focus on these
14:04:18 <edleafe> There is also the Nested Resource Providers series, starting with:
14:04:21 <edleafe> #link https://review.openstack.org/#/c/415920/
14:04:58 <edleafe> I've been nursing those through several rebases, but more eyeballs on them as far as code correctness would be appreciated
14:05:11 <edleafe> Anyone have any other specs/reviews to mention?
14:05:23 <jaypipes> edleafe: dansmith and I had some chats about that on Friday. Likely that will need to be refactored (back to what it kind of looked like originally)
14:05:45 <cdent> /o\
14:06:28 <edleafe> jaypipes: right. And without cries of YAGNI, please make sure that it works with a separate, independent placement service
14:07:03 <jaypipes> edleafe: ?
14:07:05 <edleafe> Having Nova use classes defined in Placement can be tricky
14:07:59 <edleafe> E.g., Nova doesn't import Neutron classes to work with that serviec
14:08:03 <edleafe> service
14:08:25 <jaypipes> edleafe: right, I don't think anyone disagrees with you on that? :)
14:09:08 <edleafe> I got the impression from dansmith that ResourceProvider classes and such belonged at the libvirt layer
14:09:50 <jaypipes> edleafe: no. ProviderTree is not a ResourceProvider class.
14:10:05 <jroll> what I got out of that conversation is that the virt layer should return a dict of resources, e.g. {VCPUS: 1, MEMORY_MB: 2, CUSTOM_FOO: 50}
14:10:11 <jaypipes> edleafe: it's not a nova.objects object.
14:10:31 <jroll> (but maybe I'm on the wrong conversation)
14:10:36 <edleafe> jroll: I don't have a problem with a dict
14:11:51 <jaypipes> jroll: yes, that's the right conversation. The issue is that for nested providers, that dict isn't really something that can store the hierarchy of providers and inventory. So the design question is what thing (scheduler report client? resource tracker? something else?) should be responsible for building that hierarchy of information.
14:12:33 <jroll> jaypipes: got it
14:12:40 <jroll> jaypipes: I'm not up to speed enough on nested stuff to comment :)
14:12:56 <jaypipes> jroll: edleafe argued on the first patch in that series that the virt layer should *not* be the thing that builds that tree of information. so I instead made the scheduler report client responsible for building that.
14:13:02 <jaypipes> jroll: no worries :)
14:13:27 <edleafe> jaypipes: my concern was having the virt layer use Inventory objects and such
14:13:34 <jaypipes> jroll: and dansmith was saying "why not have the virt layer build this information and return it to the resource tracker?"
14:13:51 <jaypipes> jroll: which is what I had in the first patch in that series ;)
14:14:07 <jroll> jaypipes: right, so I gathered the right idea, just not the how :)
14:14:19 <edleafe> IOW, the virt layer should know what it has and report it. It shouldn't know how the placement service represents it internally
14:14:31 <jaypipes> in any case, this is something that we should have a session about next week I think?
14:14:43 <edleafe> by all means!
14:14:45 <jroll> yep
14:14:46 <jaypipes> :)
14:14:47 <jroll> makes sense
14:15:01 * jaypipes getting way too hungry for this conversation right now :)
14:15:01 <edleafe> Any other specs/reviews?
14:15:15 <jaypipes> edleafe: well, the ironic inventory one :)
14:15:17 * edleafe needs pot of coffee #2 right now
14:15:29 <jaypipes> edleafe: needs some TLC today.
14:15:42 <edleafe> jaypipes: just rebasing TLC, or more?
14:16:31 <jroll> jaypipes: so, the ironic patch is the one that started the layering conversation, right?
14:16:41 <jaypipes> edleafe: rebasing and reviewing.
14:17:01 <jroll> IOW doesn't that depend a bit on the outcome of the previous conversation? or would you rather refactor later?
14:17:12 <edleafe> jaypipes: you need me to rebase, or do you have it?
14:17:31 <edleafe> jroll: I think it was the whole NUMA mess
14:18:09 <jroll> edleafe: iirc, dan's argument was that if we fix the layering thing, we don't need all the "if ironic" junk in the RT layer
14:18:26 <jaypipes> jroll: yes, it started the conversation. but dansmith's comments about layering in that patch led to the nested resource providers series being used as an example of what he might like to see instead..
14:18:32 <edleafe> jroll: ah, I see what you mean. Yes, that's true
14:18:51 * jroll isn't sure if we want to block on that or not, just wanted to point it out
14:19:24 <edleafe> jroll: well, the idea was that the 'if ironinc' crap was a stopgap for Ocata, but now that that ship has sailed...
14:19:46 <jaypipes> heh, yeah.
14:20:21 <jroll> :)
14:20:29 <edleafe> Looks like we won't be bored next week :)
14:20:35 <edleafe> Let's move on
14:20:39 <edleafe> #topic Bugs
14:20:46 <jaypipes> one thing I definitely do want to keep around from the Ironic inventory patch is the addition of that brand new shiny functional test for the resource tracker. :)
14:20:48 <edleafe> Any new bugs to discuss?
14:21:05 <jaypipes> glorious: https://review.openstack.org/#/c/404472/34/nova/tests/functional/compute/test_resource_tracker.py
14:21:08 <johnthetubaguy> on the layering, is the long term plan that the resource tracker dies / only cares about keeping in sync with placement, but we have moved on for now
14:21:32 <johnthetubaguy> jaypipes: thats actually quite beautiful to see
14:22:10 <jaypipes> johnthetubaguy: I've gone through quite a few design iterations on the layering stuff :) there's good things and bad things for each approach. basically, just need to hammer this out in a session in ATL I think :(
14:22:11 <edleafe> johnthetubaguy and jaypipes: that leads us to the actions from last week...
14:22:21 <edleafe> #topic Open discussion
14:22:23 <johnthetubaguy> jaypipes: yeah, it feels that way
14:22:30 <jaypipes> I can write up a quick email saying "here are the options". let's choose one.
14:22:38 <johnthetubaguy> jaypipes: that sounds great to me
14:22:44 <jroll> jaypipes: ++
14:22:46 <jaypipes> kk
14:22:48 <cdent> prepemail++
14:23:02 <edleafe> Last week cdent and I had the action assigned to outline the functional tests that we feel are needed, so that others can respond and begin writing them
14:23:04 <jaypipes> ooh, look a see-dent.
14:23:06 <johnthetubaguy> having slept on it before the PTG, will be no bad thing
14:23:46 <edleafe> We created an etherpad:
14:23:50 <edleafe> #link https://etherpad.openstack.org/p/nova-placement-functional
14:24:17 <jroll> jaypipes: that test is amaze
14:24:46 <edleafe> It would be great to take that test and use it as the basis for lots more
14:25:13 <edleafe> The other action was for bauzas, diga and macsz to begin defining the goals for Pike
14:25:28 <edleafe> Is there something for that?
14:25:42 <diga> edleafe: we drafted some on etherpad
14:25:53 <diga> #link- https://etherpad.openstack.org/p/nova-scheduler-pike
14:25:55 <edleafe> diga: link?
14:26:05 <edleafe> diga: beat me to it :)
14:26:28 <diga> edleafe: :)
14:26:52 <edleafe> So these Pike goals are definitely something we should discuss at PTG
14:27:14 <diga> edleafe: Yeah, we should
14:27:48 <diga> By the way, I am able to attend PTG
14:27:49 <edleafe> A quick read of that page doesn't show too many concrete goals - more like brainstorming
14:27:57 <edleafe> diga: that's great!
14:28:47 <diga> edleafe: sorry I am not able to attend PTG :( because travel support issue
14:28:54 <diga> type mistake
14:28:56 <edleafe> Can you guys maybe sum up the goals that you think are a) necessary to get done in Pike, and b) would be great but not critical for Pike
14:29:12 <edleafe> diga: :(
14:29:39 <diga> edleafe: sure
14:30:00 <edleafe> diga: thanks
14:30:16 <diga> edleafe: is there way to attend remotely for 1 session at least
14:30:37 <edleafe> diga: usually it's tough, and with this being the first PTG, who knows?
14:30:51 <diga> edleafe: okay, NP!
14:30:54 <edleafe> diga: I also think ttx said that most rooms won't even have projectors
14:31:15 <diga> edleafe: ohh.. i see
14:31:41 <edleafe> If anyone has opinions on what we should set as our Pike goals, please add your thoughts to that etherpad
14:32:13 <edleafe> So... anything else on your minds?
14:33:12 * edleafe is ready to go make more coffee
14:33:20 <cdent> I like coffee
14:33:35 <edleafe> I should mention that we won't be meeting next week, due to PTG
14:33:47 <edleafe> Next meeting in 2 weeks
14:34:25 <jroll> woo
14:34:41 <edleafe> OK, thanks for coming. Hope to see many of you in Atlanta!
14:34:42 <diga> ack
14:34:46 <edleafe> #endmeeting