14:00:10 <edleafe> #startmeeting nova_scheduler
14:00:11 <openstack> Meeting started Mon Jun 19 14:00:10 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:15 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:19 <mriedem> o/
14:00:22 <edleafe> Good UGT morning! Who's here?
14:00:28 <alex_xu> o/
14:00:44 <dtantsur> o/
14:01:27 <edleafe> I know that cdent is on PTO. jaypipes, dansmith - around?
14:01:44 <jaypipes> edleafe: yeah. currently replying to your email.
14:01:45 <dansmith> in another meeting, but yes
14:02:09 <edleafe> cool. Let's start
14:02:15 <edleafe> #topic Specs & Reviews
14:02:26 <edleafe> #link Nested Resources: series starting with https://review.openstack.org/#/c/415920/
14:02:44 <edleafe> Not much action on this in the past week
14:03:14 <edleafe> Probably because of the focus on this:
14:03:15 <edleafe> #link Alternate Allocations https://review.openstack.org/#/c/473377/
14:03:18 <edleafe> #link Spec: https://review.openstack.org/#/c/471927/
14:03:47 <edleafe> I posted an email about clarifying where this is headed
14:03:56 <edleafe> #link email thread on direction: http://lists.openstack.org/pipermail/openstack-dev/2017-June/118572.html
14:04:08 <edleafe> I thought we'd discuss it in Open Discussion
14:04:22 <edleafe> #link project_id and user_id in PUT /allocations: https://review.openstack.org/#/c/469634/
14:04:26 <edleafe> Both patches in that series need a second +2
14:05:26 <edleafe> #link Delete all inventory: https://review.openstack.org/#/c/460147/
14:05:38 <edleafe> After a lot of back-and-forth, this looks ready; needs some +2s
14:05:56 <edleafe> #link Placement API ref docs: https://review.openstack.org/#/q/topic:cd/placement-api-ref+status:open
14:06:02 <edleafe> The list is getting shorter! Great work there!
14:06:46 <edleafe> Any other specs or reviews anyone wants to discuss?
14:07:11 <jaypipes> edleafe: I'll be pushing the next in the allocation candidates series shortly..
14:07:17 <jaypipes> edleafe: have the REST API part done.
14:07:23 <jaypipes> edleafe: then moving on to scheduler.
14:07:32 <edleafe> jaypipes: that's great
14:08:30 <edleafe> Moving on...
14:08:33 <edleafe> #topic Bugs
14:08:39 <edleafe> #link Placement bugs https://bugs.launchpad.net/nova/+bugs?field.tag=placement
14:08:43 <edleafe> One new bug reported last week; status is still undecided
14:09:03 <edleafe> Any other bug-related issues?
14:09:32 * bauzas waves late because daughter to pick at school
14:09:41 * edleafe waves back
14:10:12 * edleafe enjoys that daughter has graduated and can drive herself around
14:11:44 <edleafe> OK, on to...
14:11:46 <edleafe> #topic Open discussion
14:11:49 <edleafe> The main topic is Jay's patch for "alternate" allocations. It is still unclear to many of us what the end game is here, so I started the email thread linked above.
14:12:00 <edleafe> I think that if that's clearer, we can all help push it forward more quickly, without the uncertainty of wondering if a change is what is needed.
14:12:02 <bauzas> edleafe: hah, still 9 years to await for her then :)
14:12:22 <jaypipes> edleafe: I highly doubt that.
14:12:49 <mriedem> edleafe: the email confused me
14:12:53 <bauzas> so, the first prio of prios for our scheduler prio is https://review.openstack.org/#/c/473377/ right?
14:12:54 <mriedem> the "existing flow" i mean
14:13:17 <edleafe> mriedem: yeah, I realized I should have said "the original plan"
14:13:21 <edleafe> or something like that
14:13:23 <mriedem> edleafe: the "current flow" in your email is really talking about the series of proposed changes before the allocation candidates stuff right?
14:13:26 <mriedem> ok
14:13:34 <mriedem> because current flow for changes not yet merged is confusing :)
14:14:19 <edleafe> mea culpa
14:14:36 <edleafe> but to be fair, I wrote that this morning while still on my first pot of coffee
14:14:55 <edleafe> so be thankful that it makes any sense at all :)
14:17:12 <edleafe> IAC, it would be much easier for me to review these things if I had an understanding of the end game
14:17:51 <mriedem> "Scheduler then runs this data through the filters and weighers. No HostState objects are required, as the data structures will contain all the information that scheduler will need."
14:18:03 <jaypipes> edleafe: k, replied to your ML post.
14:18:06 <mriedem> is ^ in the spec? i haven't read the spec, but i assume we'll still be creating HostState objects
14:18:16 <mriedem> b/c the scheduler code is working on those types of objects, not dicts
14:18:19 <jaypipes> mriedem: no.
14:18:24 <edleafe> mriedem: eventually we are getting rid of HostState
14:21:27 <jaypipes> mriedem: we'll still need host state objects for some things I'm sure, because Placement isn't going to be responsible for a bunch of things like thermal sensor metrics that operators insisted on being able to weigh hosts with.
14:22:05 <edleafe> oh
14:22:29 <edleafe> and I thought they were going away
14:22:46 <edleafe> which is why we couldn't include nested resource UUIDs in them
14:22:59 <bauzas> I need to look at the ML post
14:23:04 <edleafe> guess I better read Jay's reply before I say anything else :)
14:23:16 <bauzas> I haven't read it yet
14:23:34 <edleafe> So unless there is anything else for open discussion, I suggest we continue this on the ML and possibly in -nova
14:23:51 <mriedem> i'm ready to +2 jay's bottom allocation candidates change,
14:23:52 <jaypipes> edleafe: good with me. I need to get back to the patches anyway.
14:23:59 <mriedem> just waiting for comments to be addressed, which it sounds like he is
14:24:02 <edleafe> ok, thanks all!
14:24:05 <edleafe> #endmeeting