14:01:28 <edleafe> #startmeeting nova_scheduler
14:01:29 <openstack> Meeting started Mon Apr 18 14:01:28 2016 UTC and is due to finish in 60 minutes.  The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:32 <openstack> The meeting name has been set to 'nova_scheduler'
14:01:41 <mriedem> o/
14:01:45 <mlavalle> o/
14:01:48 <edleafe> Just FYI - having network problems today
14:01:54 <Yingxin> \o
14:01:56 <jaypipes> \o/
14:01:58 <edleafe> lots of thunderstorms moving through south texas
14:02:04 <sarafraj> o/
14:02:10 <jaypipes> edleafe: excuses, excuses...
14:02:12 <edleafe> so if I disappear, I'm probably floating away somewhere
14:02:22 <jaypipes> edleafe: :)
14:02:24 <mlavalle> yeap, poring down in San Antonio
14:02:37 <edleafe> #topic Meeting reminder
14:02:37 <edleafe> Please note that there will be no meeting next Monday, as most of us will be in Austin for the OpenStack Summit.
14:02:47 <edleafe> #topic Specs
14:02:51 <edleafe> Jay's spec for Generic Resource pools is on hold until after the summit, but we can still review/comment now, so that when the hold is lifted, it can move forward quickly.
14:02:57 <edleafe> #link https://review.openstack.org/#/c/300176/
14:03:05 <edleafe> Jay - anything to add on that spec?
14:03:06 * bauzas waves late
14:03:16 <_gryf> o/
14:03:20 <jaypipes> ++, same for resource allocation migrations: https://review.openstack.org/#/c/300177/
14:03:34 <edleafe> #link https://review.openstack.org/#/c/300177/
14:03:52 <edleafe> #topic Reviews
14:03:58 <edleafe> Add name to ResourceProvider object
14:03:58 <edleafe> #link https://review.openstack.org/#/c/281945/
14:04:23 <edleafe> Is cdent here?
14:04:28 <jaypipes> edleafe: I went ahead and made placeholder blueprints for a bunch of things to visualize the end state of a broken out scheduler. You can see the relationship of blueprints in the compute-node-inventory-newton LP blueprint page here:
14:04:31 <jaypipes> #link https://blueprints.launchpad.net/nova/+spec/compute-node-inventory-newton
14:04:31 <edleafe> saw him in -nova earlier
14:05:07 <Yingxin> saw him replied my spec just now.
14:05:15 <edleafe> jaypipes: thanks, that's a good addition
14:05:17 <jaypipes> bauzas: you will note in the link above in the dependency graph that I have *not* made the shceduler db filter nor the claims in scheduler a dependency for a broken out scheduler.
14:05:55 <jaypipes> I pinged cdent on slack.
14:06:00 <jaypipes> he'll be here shortly.
14:06:01 <bauzas> jaypipes: thanks
14:06:12 <bauzas> jaypipes: I appreciate that :)
14:06:17 <Yingxin> I'm writing the spec for eventually-consistent-host-states, will be based on generic-resource-pools.
14:06:30 <jaypipes> bauzas: I'm still going to push for those, but made them not a dependency ;)
14:06:31 <Yingxin> #link  https://review.openstack.org/#/c/306844/
14:06:39 <bauzas> jaypipes: that's totally reasonable
14:07:02 <edleafe> jaypipes: yeah, they are kinda orthogonal to the split
14:07:03 <mlavalle> jaypipes: so code for resource pools will be in this gerrit topic: https://review.openstack.org/#/q/topic:bp/generic-resource-pools,n,z
14:07:07 <bauzas> jaypipes: like I said multiple times, I'm not sold against or pro the idea, just feeling we need to be clear about what we land and why :)
14:07:30 <bauzas> jaypipes: so those could be properly evaluated once we get the bits we want :)
14:07:32 <jaypipes> on the routed networks spec... mlavalle and carl_baldwin I had long talks this weekend with dansmith and share some of his concerns on the spec around what to do in some of the special pre-allocated-pre-associated-ip ports.
14:07:49 <jaypipes> bauzas: yup, totes.
14:08:22 <mlavalle> jaypipes: should we meet in Austin o discuss it face to face?
14:08:35 <jaypipes> mlavalle: erm, maybe? :) that branch/topic is light. there's other things that cdent was working on in a couple other branches.
14:08:44 <jaypipes> mlavalle: I'll have cdent ping you links.
14:09:08 <bauzas> jaypipes: mlavalle: we will have 80 mins for discussing all the topics about that :)
14:09:16 <jaypipes> mlavalle: no, on the routed networks spec, I will add comments to the review, you can read, then we can do a high-bw conversation with dansmith and carl_baldwin , ok?
14:09:27 * dansmith nods
14:09:33 <mlavalle> jaypipes: that's perfect. Thanks
14:09:36 <bauzas> jaypipes: have you had time to focus on what you want to reach for the 2 sessions ?
14:09:48 <jaypipes> mlavalle: that way by the time the summit rolls around we won't have too much (hopefully) back and forth that drains the session time.
14:10:09 <edleafe> bauzas: that's later on the agenda
14:10:18 <jaypipes> bauzas: I was figuring that you and I would just argue about cheese most of that time slot.
14:10:31 <edleafe> There are two other reviews that I had marked
14:10:33 <bauzas> jaypipes: that's a perfect time for that
14:10:33 <mlavalle> jaypipes: yeah. that sounds great. let's have that high bandwidth conversation this week
14:10:34 <edleafe> Add ResourcePool and ResourcePoolList objects
14:10:34 <edleafe> #link https://review.openstack.org/#/c/284963/
14:10:40 <edleafe> Add Allocation and AllocationList objects
14:10:40 <edleafe> #link https://review.openstack.org/#/c/282442/
14:10:55 <mriedem> mlavalle: jaypipes: i expect routed networks to come up in the nova/neutron session on wed at the summit too
14:11:10 <mriedem> but would be best to have that mostly ironed out beforehand
14:11:11 <jaypipes> edleafe: yeah, that second one is for the resource-providers-allocations blueprint, which migrates usage data to the allocations table.
14:11:21 <mlavalle> mriedem: ++
14:11:27 <jaypipes> yup, ++
14:11:30 <bauzas> ++
14:11:44 <edleafe> agreed, the sessions always seem too short
14:12:07 <bauzas> mlavalle: I also heard of a notion of QoS from Neutron to send to Nova, right?
14:12:23 <jaypipes> bauzas: I've been chatting with ajo on that one.
14:12:24 <bauzas> so we could filter based on those metrics AFAICS
14:12:32 <bauzas> okay
14:12:33 <mlavalle> bauzas: ajo is the one to talk about that
14:12:55 <bauzas> fair enough
14:12:59 <ajo> ji
14:13:01 <ajo> hi
14:13:10 <jaypipes> bauzas: the routed networks is the higher priority use case at the moment, from what I can tell, but I thinkt he QoS requirements can be easily met by the generic-resource-pools functionality as well.
14:13:21 <bauzas> cool then
14:13:33 <ajo> my only worry, is, that for what we were talking on the mail list
14:13:42 <ajo> we end up adding another call to the neutron API,
14:13:54 <ajo> to translate a port id, to "resource usages"
14:13:59 <bauzas> *to* the Neutron API ?
14:14:24 <ajo> bauzas, fron the port dictionary, you can't know exactly how much resources (BW in this case) is using
14:14:37 <ajo> bauzas, that's tied to the QoS policy the port is attached to
14:15:00 <bauzas> I was seeing neutron updating us the resource information
14:15:02 <mriedem> ajo: what's the alternative?
14:15:07 <ajo> so you can either call neutron qos, grab the policy, and make your own interpretation (in that case you need to tightly couple nova to the knowledge of that)
14:15:08 <jaypipes> bauzas: as for the summit session, I plan to focus a good 30 minutes on getting a gameplan together for aligning when the quantitative and qualitative sides of the scheduler equation will meet. Right now, alex_xu, claudiub and a few others have been working on the qualitative side (host capabilities and other proposals) and obviously we've been focused on the resource amounts (quantitative) side. we need to ensure we understand when the two
14:15:08 <jaypipes> sides will be aligned.
14:15:12 <ajo> or..
14:15:18 <bauzas> what the semantics of the resource usage is not something the scheduler should know
14:15:28 <ajo> the other option, is asking neutron to translate that object into "resource consumptions from you"
14:15:29 <ajo> but
14:15:45 <ajo> that defeats the original thinking of... "let's avoid scheduler calling other projects via API"
14:15:49 <ajo> is my only worry
14:15:51 <bauzas> jaypipes: I agree with that, that's a good point
14:16:20 <edleafe> OK, any other reviews to note?
14:16:48 <edleafe> moving on...
14:16:51 <edleafe> #topic Summit Schedule
14:17:00 <ajo> jaypipes, I had this thought just today, I will translate it to the mail list for further discussion
14:17:00 <bauzas> ajo: what I'm feeling is that neutron should send us a quantitative amount of resources to pick from, but what the resources are is totally blind to the scheduler, hence not needing a callback
14:17:24 <jaypipes> ajo: ++
14:17:32 <edleafe> #undo
14:17:32 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x9a1ea50>
14:18:04 <ajo> bauzas, but it's nova who creates the port, or grabs the port via ID... we can't send you all the info related to ports in advance, but, ok let's keep discussing
14:19:30 <jaypipes> ajo: yeah, let's save that for a ML thread, cool?
14:19:36 <bauzas> ajo: jaypipes: +1
14:19:36 <edleafe> Yes, let's continue that discussion for email
14:19:41 <edleafe> jink!
14:19:46 <edleafe> jinx, even
14:19:46 <ajo> +1
14:19:58 <edleafe> #topic Summit Schedule
14:19:59 <ajo> thank you guys
14:20:03 <edleafe> We have two 40-minute sessions that start Wed. at 9am
14:20:24 <edleafe> jaypipes: anything else to add on your ideas for those slots?
14:20:37 <bauzas> some great anonymous created the session etherpads :)
14:20:51 <edleafe> bauzas: link?
14:20:51 <bauzas> I guess it's either mriedem or sdague
14:21:12 <bauzas> edleafe: sure, once the summit schedule website will make me happy
14:21:21 <jaypipes> edleafe: I had a nice hangout with timhinrichs about the policy scheduler proposal. He has abandoned that and based on our chat reworking a few things. I'd like to take 10-15 minutes at the end of the sessions to summarize long-term plans in the scheduler space.
14:21:27 <edleafe> bauzas: that'll never happen :(
14:21:28 <bauzas> https://www.openstack.org/summit/austin-2016/summit-schedule/events/9087?goback=1
14:21:37 <bauzas> which points to https://etherpad.openstack.org/p/newton-nova-scheduler
14:21:43 <mriedem> the nova summit etherpads are here https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Nova
14:21:47 <mriedem> they are mostly bare
14:21:51 <mriedem> and we need to start filling them in,
14:22:03 <jaypipes> mriedem: will do this week, promise.
14:22:06 <mriedem> which if it's left to me, i'm going to just mostly copy the contents from the ideas etherpad
14:22:14 <edleafe> #link https://etherpad.openstack.org/p/newton-nova-scheduler
14:22:23 <edleafe> #link https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Nova
14:22:53 <bauzas> jaypipes: cool, I appreciate discussing on leaving a bit of discussion for something else than resource-* :p
14:23:01 <edleafe> mriedem: huh, I thought you would have filled the sessions with obscure 80s music references
14:23:06 <bauzas> s/discussing on//
14:23:08 <jaypipes> hehe
14:23:27 <bauzas> or my brain would litterally explose
14:23:30 <bauzas> :p
14:23:54 <edleafe> #action jaypipes to fill out etherpad for scheduler discussion items
14:24:16 <jaypipes> bauzas: added a TODO for you in the etherpad.
14:24:24 <bauzas> hah
14:24:34 <bauzas> I'm pretty sure I couldn't bring cheese with me
14:24:50 <bauzas> or I would get kicked-off the border by the TSA guys :p
14:24:51 <mriedem> btw the ideas etherpad is here https://etherpad.openstack.org/p/newton-nova-summit-ideas
14:25:05 <mriedem> #link original newton summit session ideas etherpad https://etherpad.openstack.org/p/newton-nova-summit-ideas
14:25:11 <edleafe> bauzas: roquefort FTW!
14:26:00 <edleafe> Sooooo... anything else to discuss about the summit?
14:26:08 <jaypipes> not from em.
14:26:11 <jaypipes> me.
14:26:20 <Yingxin> Possible to add discussing about shared-state-scheduler?
14:26:21 <bauzas> I was about to discuss a bit of the ReqSpec
14:26:38 <bauzas> but that's a bit consensual
14:26:45 <bauzas> (basically passing it everywhere)
14:26:55 <bauzas> so, it's not really a huge deal
14:27:02 <moshele> is it possible discuss to with Device Capabilities https://review.openstack.org/#/c/286073/ ?
14:27:04 <jaypipes> Yingxin: you will be in Austin?
14:27:09 <edleafe> moshele: that's next
14:27:14 <Yingxin> jaypipes: yes
14:27:25 <jaypipes> Yingxin: cool, I will add it to the schedule
14:27:42 <edleafe> Yes, I'd like to hear more about shared-state scheduler
14:27:50 <Yingxin> jaypipes: thanks
14:27:56 <Yingxin> glad to meet you f2f
14:28:06 <jaypipes> ditto
14:28:07 <bauzas> what I'd like is to identify the timeline we'd get for the changes we're going to introduce
14:28:13 <_gryf> i'd like to discuss about not trivial resources
14:28:20 <_gryf> like fpga or gpus
14:28:41 <edleafe> heh, every time I try to type 'schedule', I end up adding an 'r' at the end
14:28:58 <bauzas> _gryf: I would leave that for either the performance VM discussion or rather the friday timeslot
14:28:58 <mriedem> _gryf: that will probably come up in the performance VMs session on wed
14:29:03 <mriedem> ++
14:29:18 <_gryf> bauzas, oh, right :)
14:29:23 <mriedem> i really really don't want the 2 scheduler sessions bogged down in far out new features
14:29:30 <_gryf> mriedem, ++
14:29:32 <mriedem> when we already have a large backlog
14:29:40 <bauzas> and we wouldn't have time to discuss that property
14:29:49 <bauzas> properly (sorry, fat fingers)
14:30:37 <edleafe> We can continue the session ideas on the etherpad and/or in -nova
14:30:42 <edleafe> #topic Open discussion
14:30:47 <edleafe> Only one added to the agenda: Scheduling with Device Capabilities
14:30:47 <edleafe> #link https://review.openstack.org/#/c/286073/
14:30:53 <edleafe> moshele: you're up
14:31:13 <bauzas> that reminds me some spec from claudiub
14:31:14 <moshele> yes so I want to address the qualitative sides
14:31:57 <bauzas> right, that's not something we consume
14:31:58 <moshele> of resource to be able to build like framework so it will be easy to add device/resource to nova
14:33:24 <moshele> so the idea it to create table which all the devices with all the qualitative capabilities
14:33:33 <jaypipes> moshele: the *very* first step I'd like to see from you and others in this space (alex_xu, malini bhandaru, etc) is to have a *single* agreed-upon set of codes that describe capabilities of things.
14:34:39 <jaypipes> moshele: there has been a suggestion in the past to use CIM, which was roundly rejected, though using the bottom-level string codes within some CIM namespaces might be doable for describing things like CPU features. What need this otherwise there will be no portability or interoperability between clouds running OpenStack.
14:35:04 <moshele> jaypipes: so I am familiar with nic and PCI and I want to make it more generic for all resource
14:35:30 <jaypipes> moshele: so, to summarize, it's cool to propose a schema or object model for storing such capabilities, but first things first, those capabilities codes need to be standardzed and placed in a library or common consts file.
14:35:35 <bauzas> jaypipes: moshele: https://review.openstack.org/#/c/222200/ is the spec I was thinking about
14:36:04 <jaypipes> bauzas: yup, I'm familiar with that one, and alex_xu's proposal that is dependent on it.
14:36:13 <bauzas> okay
14:37:18 <jaypipes> bauzas: claudiu's spec is more about a discovery API for hypervisor functionality, whereas moshele is more interested in the PCI device capabilities and flags.
14:37:34 <bauzas> I agree
14:37:43 <bauzas> (just reading moshele's spec proposal
14:37:48 <moshele> not just pci for every device
14:38:08 <moshele> devices that we would add in the future as well
14:38:15 <edleafe> jaypipes: good point. Looks like an abstraction needs to be created so we don't keep one-offing these
14:38:24 <bauzas> but that's very related to the session I want to discuss in the performance VM session
14:38:37 <bauzas> because that PCI tracking is honestly a PITA to me
14:38:52 <bauzas> https://etherpad.openstack.org/p/newton-nova-performance-vms
14:39:30 <johnthetubaguy> oh, that what we mean by performance vms then, I did want to go look that up
14:39:42 <bauzas> jaypipes: I was taking the PCI resource tracking in that session because I was feeling it was requiring a full dedicated session and not polluting the sched sessions
14:40:36 <moshele> I think the PCI problem is  different story  legacy problem, but we should look also for new devices and resources and how to plug them to the scheduler
14:40:53 * bauzas bbiab, just kicking-off my cat's butt
14:41:00 <moshele> looking on the qualitative sides
14:41:09 <jaypipes> moshele: I prioritize cleaning up the cruft we have in the resource tracker and PCI handling code over adding new features around PCI devices.
14:41:33 <bauzas> ++
14:42:13 <jaypipes> moshele: that said, if you can shape your proposal to be about a common, consistent representation of these capabilities (and a library that would allow any service project to agree on what a code for a capability means), I would think that would be a great first step.
14:42:30 <jaypipes> moshele: think of it kind of like our discussion around the osinfo library.
14:42:54 <moshele> osinfo?
14:43:04 <jaypipes> moshele: we needed a place to standardize how we described operating system capabilities and definitions. osinfo was that library (for better or worse, but it was what we decided upon)
14:44:20 <moshele> jaypipes: can you send me a link to osinfo library
14:45:49 <jaypipes> moshele: sure, gimme a sec
14:46:39 <jaypipes> moshele: https://libosinfo.org/ and it is utilized in Nova here: https://github.com/openstack/nova/blob/master/nova/virt/osinfo.py
14:47:06 <moshele> jaypipes: by the way I am working on fixing the pci code for resize and migration and I saw you proposal of removing the pci.stats module and moving the logic to the scheduler, so this should clean the pci code or there is something else
14:47:56 <jaypipes> moshele: yes, that is my proposal (or most of it). I need to refactor that original spec to include the device.tags mess that ndipanov rightfully brought up in code review and resubmit the spec for Newton.
14:47:56 <edleafe> Anything else for opens?
14:48:13 <Yingxin> edleafe: yes
14:48:22 <edleafe> Yingxin: go ahead
14:48:28 <Yingxin> Anyone interested in nova scheduler performance profiling, here is an advertisement:
14:48:35 <Yingxin> http://paste.openstack.org/show/494336/
14:48:43 <Yingxin> for the summit session
14:49:18 <Yingxin> edleafe: done
14:49:34 <edleafe> ok
14:49:38 <edleafe> anything else?
14:49:50 <edleafe> Or should we return to bug scrubbing?
14:49:57 <jaypipes> Yingxin: wait, this is a conference session or a design summit session?
14:50:20 <Yingxin> jaypipes: conference session
14:50:38 <Yingxin> https://www.openstack.org/summit/austin-2016/summit-schedule/events/7129
14:50:43 <jaypipes> Yingxin: k, I will try my best to attend.
14:50:50 <bauzas> argh
14:50:54 <jaypipes> Yingxin: I'll sit in the front row and heckle you :P
14:51:03 <bauzas> possibly the least possible session to attend
14:51:03 <Yingxin> jaypipes: :)
14:51:14 <jaypipes> bauzas: conflict?
14:51:15 <bauzas> one of the last nova design dessions
14:51:20 <jaypipes> guh, shit.
14:51:49 <bauzas> jaypipes: well, I'm just trying to figure out which one in conflict
14:52:05 <bauzas> now, everyone should know how I hate the new sched website
14:52:17 <bauzas> please, please, free us sched.org
14:52:27 <edleafe> bauzas: ++++
14:52:51 <bauzas> I could even make a donation campaign
14:53:04 <bauzas> if that's a cost problem
14:53:37 <bauzas> aaaaand, my browser crashed on trying to get my sched
14:53:43 <edleafe> I'm sure the foundation can afford a decent schedule app
14:54:13 <edleafe> Any other topics for Opens?
14:54:16 <bauzas> yeah, so Yingxin's session is conflicting with the nova-ironic joint session :/
14:54:43 <Yingxin> bauzas: I can write a summary to maillist for you
14:54:45 <jaypipes> bauzas: yeah :(
14:54:59 <bauzas> Yingxin: not needed, it should be recorded
14:55:08 <edleafe> Now you know why I resist management's insisting on giving talks at a summit
14:55:26 <bauzas> Yingxin: in general, I prefer attending design sessions for the exact reason that conf sessions are recorded while design sessions aren't
14:55:56 <bauzas> trying to get the consensus on something you didn't attended is hard
14:56:20 <bauzas> anyway
14:56:30 <edleafe> bauzas: yeah, not every agreement is written down
14:56:34 <bauzas> I enough ranted for today
14:56:44 <edleafe> ok, let's move on
14:56:46 <Yingxin> bauzas: good suggestion
14:56:57 <edleafe> see you all (or at least most of you) in Austin next week!
14:57:06 <edleafe> #endmeeting nova_scheduler