14:01:56 <cdent> #startmeeting nova_scheduler
14:01:56 <openstack> Meeting started Mon Jul  9 14:01:56 2018 UTC and is due to finish in 60 minutes.  The chair is cdent. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:00 <openstack> The meeting name has been set to 'nova_scheduler'
14:02:04 <efried> ō/
14:02:05 <takashin> o/
14:02:05 <tssurya> o/
14:02:09 <cdent> #chair efried edleafe jaypipes bauzas tetsuro
14:02:10 <openstack> Current chairs: bauzas cdent edleafe efried jaypipes tetsuro
14:02:17 <edleafe> \o
14:02:18 <tetsuro> o/
14:02:19 <cdent> #chair gibi
14:02:19 <openstack> Current chairs: bauzas cdent edleafe efried gibi jaypipes tetsuro
14:02:32 <Jack1> o/
14:02:40 <cdent> #link agenda https://wiki.openstack.org/wiki/Meetings/NovaScheduler
14:03:07 <jaypipes> o/
14:03:10 <cdent> #topic last meeting
14:03:15 <cdent> #link last minutes: http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-07-02-14.00.html
14:03:16 <gibi> o/
14:03:31 <cdent> no specific action items from the last meeting
14:03:41 <cdent> any carry overs from that that people would like to bring up?
14:03:48 <jaypipes> are we still prioritizing the reshaper items?
14:04:08 <efried> As in, setting their priority, or as in, making them a top priority?
14:04:53 <cdent> my understanding has been that we have to get the reshaper done in order for other stuff to be useful. Is that not actually the case?
14:05:35 <efried> Only for drivers that need to move existing resources from the compute node provider to child providers.
14:05:47 * alex_xu waves late
14:05:59 <jaypipes> efried: the latter
14:06:00 <efried> Drivers enabling child providers with heretofore nonexistent resources can proceed without it.
14:06:27 <efried> IIUC, we have a couple of drivers with VGPUs on the compute node RP in Queens, true?
14:07:00 <efried> So those can't use nrp until /reshaper is in place.
14:07:27 <jaypipes> efried: NUMA is not possible without the reshaper, since all the PCPU/VCPU work to allocate buckets of guest CPU resources per NUMA node (and take those buckets away from the compute node provider) is not possible without the reshaper work being completed.
14:07:36 <efried> Likewise if we want to implement NUMA where VCPU resources from the compute RP are going to get split up into VCPU&PCPU resources on child providers representing NUMA nodes...
14:07:39 <efried> yeah, what jaypipes said.
14:08:16 <cdent> so I think that means "yes, unless we want to go on a big delay"
14:08:16 <efried> So - if those things are considered important, then yeah, /reshaper is mas important.
14:08:47 <cdent> jaypipes: was there something that made you think we had chosen not to?
14:10:16 <jaypipes> cdent: no, not at all. I just think the reshaper effort might be slowed down due to so many people actively working on it at once.
14:10:56 <cdent> "so many"?
14:11:07 <jaypipes> cdent: and due to that, would probably be a good idea to have a single person leading the effort overall (i.e. project management)
14:11:18 <jaypipes> cdent: yes, there's at least 4 different engineers working on it.
14:11:24 <mriedem> are there patches ready for review?
14:11:34 * cdent was aware of only 3
14:11:35 <mriedem> i personally just don't know what state it's in review-wise
14:11:50 <mriedem> and i'm distracted by all of the other open stuff and things i have to already do myself
14:12:06 <jaypipes> mriedem: I wasn't suggesting you personally needed to project manage.
14:12:14 <mriedem> we could use the review priorities etherpad to dump things that are ready to review for reshaper
14:12:17 <mriedem> jaypipes: i know,
14:12:26 <mriedem> but i'm saying, that's why i'm personally unaware of it's status
14:12:47 <mriedem> sorry, its - i know efried is cringing
14:13:14 <mriedem> i'm also worried it's not getting attention from the whole team though (myself included)
14:13:39 <efried> Project management lite: Agree we should at least have a list of work items with names next to them.
14:13:49 <efried> which, unless I am mistaken, is in the spec.
14:13:56 <mriedem> it is
14:14:02 <cdent> jaypipes: last I checked efried is blocked on me and I'm blocked on you (as described by the spec)
14:14:15 <jaypipes> cdent: when I say "at least 4" I am referring to the spec itself, which lists under Assignees the following:
14:14:16 <jaypipes> * `Placement POST /reshaper`_: jaypipes (SQL-fu), cdent (API plumbing)
14:14:16 <jaypipes> * `Direct Interface to Placement`_: cdent
14:14:16 <jaypipes> * Report client, resource tracker, virt driver parity: efried
14:14:16 <jaypipes> * `Offline Upgrade Script`_: dansmith
14:14:17 <jaypipes> * Reviews and general heckling: mriedem, bauzas, gibi, edleafe, alex_xu
14:14:43 <jaypipes> cdent: ok, so I'm the blocking factor.
14:14:45 <cdent> and dansmith is blocked on efried
14:15:29 <efried> I've got some progress I can make before I'm totally blocked - I can at least *write* the resourcetracker/reportclient side of things, which I haven't finished yet.
14:15:43 <jaypipes> I'm been focused on the consumer cleanup stuff/bugs.
14:15:52 <efried> it won't be usable until the /reshaper op is done, but it can at least be brought to reviewable state.
14:16:21 <efried> so what do we need here, a PMP to bug folks for progress on a regular?
14:16:54 <jaypipes> efried: someone to say "hey, Jay, you're blocking progress on X by not doing Y".
14:17:21 <mriedem> feature freeze is july 26,
14:17:25 <efried> Swhat I'm asking.  Is that necessary?  Or put another way, would it be helpful?
14:17:36 <mriedem> so looking at the schedule, we realistically have until the end of this week to have an API to test against
14:17:57 <mriedem> and that leaves about 1.5 weeks for the other client side bits to land
14:18:34 <mriedem> so if the sql-fu could be done by eod wednesday, that's on track right?
14:18:52 <cdent> the api framework is (vaguely) ready to be wried in: https://review.openstack.org/#/c/576927/
14:19:23 <mriedem> jaypipes: do you think you could have the sql bits done by eod wednesday?
14:19:33 <mriedem> if you do consumer bug stuff today?
14:19:48 <jaypipes> mriedem: I'm reading cdent's patch now to get a better idea of how I'd need to provide the interface that meets his needs.
14:20:00 <mriedem> ok so i guess we should move on
14:20:05 <jaypipes> mriedem: and there are 4 separate consumer-related bugs I'm currently trying to tackle.
14:20:26 <cdent> any of that which can be passed around?
14:20:27 <mriedem> let's talk about those in the bugs section of the meeting (is that a thing?)
14:20:37 <jaypipes> yes
14:20:47 <cdent> #topic specs and review
14:20:48 <cdent> #link latest pupdate: http://lists.openstack.org/pipermail/openstack-dev/2018-July/132038.html
14:20:53 <mriedem> btw,
14:21:07 <mriedem> melwitt should probably be brought up to speed on reshaper sooner than later
14:21:15 <cdent> other than what we just talked about (and not bugs) what pending reviews need additional attention?
14:21:37 <cdent> which of jaypipes or efried would like that action?
14:21:43 <cdent> (the inform melwitt action)
14:22:33 <mriedem> i can ping her in -nova later
14:22:41 <mriedem> to read this meeting's logs
14:23:18 <jaypipes> ty mriedem
14:23:38 <cdent> any other reviews need special attention? the big deals of the moment are reshaper (above) and consumer (in next topic)
14:24:30 <cdent> #topic bugs
14:24:30 <cdent> #link placement bugs: https://bugs.launchpad.net/nova/+bugs?field.tag=placement&orderby=-id
14:24:46 <cdent> so, consumer-related bugs. go.
14:25:04 <mriedem> the one i need fixed is the one to be able to change consumers on an existing allocation
14:25:12 <mriedem> for heal_allocations to work
14:25:31 <efried> jaypipes: is that included in any of your currently-proposed patches?
14:25:41 <mriedem> need a 2nd core on these https://review.openstack.org/#/q/topic:bug/1779725+(status:open+OR+status:merged)
14:25:43 <mriedem> dansmith: ^
14:26:04 <dansmith> ack
14:27:22 <jaypipes> mriedem, efried: no. someone else could work on it. the problem is that the other bugs I'm working around consumers (auto-created consumers should get deleted, delete consumers that have no more allocations, as well as the single transaction sql-fu for reshaper) all touch the exact same part of the codebase and thus are ripe for rebase conflicts.
14:27:40 <efried> mm
14:27:55 <mriedem> i could take a look at the one i need fixed
14:28:02 <jaypipes> efried: I can have something pushed for the "modify consumer project/user" bug within a couple hours.
14:28:14 <jaypipes> mriedem: again, it's just rebase hell for me.
14:28:30 <efried> jaypipes: It sounds like it might be best, whether it's you or mriedem, to put it into series with the other related patches, even though they're sort of part of separate efforts.
14:28:31 <mriedem> ok, well, tell me if you are going to focus on it and i'll do something else
14:28:31 <jaypipes> mriedem: since all these patches touch the same code.
14:28:49 <efried> ...to minimize rebase pain
14:29:24 <mriedem> in case it's not clear, i'm talking about https://bugs.launchpad.net/nova/+bug/1779717
14:29:24 <openstack> Launchpad bug 1779717 in OpenStack Compute (nova) "No ability to update consumer's project and/or user external ID" [Medium,Triaged] - Assigned to Jay Pipes (jaypipes)
14:29:26 <jaypipes> efried: whenever I do that I get bitched at for putting them in a series because inevitably someone says "well, if you didn't have this in the series, we could merge this particular piece separately."
14:29:44 <jaypipes> mriedem: ack, yes, that's the one.
14:30:00 <efried> So if we agree beforehand that that's the right thing to do in this particular case, we can avoid the bitching *and* the rebase pain.  Can we agree on that?
14:30:01 <mriedem> jaypipes: ok so you're going to work on it - if you don't get a chance let me know and i can investigate the fix
14:30:21 <jaypipes> mriedem: I shall have something up in a couple hours.
14:31:03 <jaypipes> mriedem: note that I pushed a number of patches for these bugs originally but folks didn't like them because they kept consumers around that didn't have allocations, so I had to abandon those earlier efforts.
14:31:54 <jaypipes> efried: not sure what you're asking for. could you elaborate?
14:32:09 <efried> dansmith, jaypipes: FYI, just +A'd https://review.openstack.org/#/c/579920/ (first of the https://review.openstack.org/#/q/topic:bug/1779725+(status:open+OR+status:merged) series)
14:32:24 <mriedem> jaypipes: efried is saying if you want to avoid rebase hell, stack the changes,
14:32:25 <dansmith> mkay
14:32:27 * dansmith closes tab
14:32:30 <mriedem> if we agree here and now that it's ok to do so
14:32:34 <mriedem> i do'nt care if they are stacked
14:32:36 <jaypipes> efried, mriedem, cdent: do we need a new microversion for fixing the "consumer project and user are not modified in PUT|POST /allocations"  calls?
14:32:36 <efried> right, that.
14:32:49 <efried> good question, Daniel-san
14:32:59 <efried> I would imagine we do :(
14:33:18 <efried> What happens right now if you try to do that?  400?
14:33:22 <mriedem> nothing
14:33:24 <mriedem> it's ignored i thought
14:33:30 <efried> hm
14:33:35 <mriedem> b/c *a* consumer already exists for the allocation
14:33:39 <mriedem> i'd say we don't need a new microversion
14:33:44 <mriedem> there is no change to the request/response
14:33:51 <mriedem> it's fixing a bug
14:34:09 <efried> Well, the response would have the new proj/user instead of the old, if you're correct about it currently being ignored.
14:34:31 <mriedem> if I PUT /allocations/{consumer} with new project/user and get the old back, it's a bug
14:34:35 <mriedem> not something i'm relying on as a client
14:34:50 <mriedem> if that were intentional, the api should be giving me a 400
14:34:56 <mriedem> i.e. if those were read-only fields
14:34:56 <efried> I can buy it.  But I tend to be lax on these things.
14:35:19 <mriedem> jaypipes: so no new microversion for that one imo
14:35:24 <cdent> fine with me
14:35:25 <jaypipes> cdent?
14:35:29 <jaypipes> k, roger
14:35:31 <efried> schweet
14:35:41 * efried practices German ^
14:35:45 <jaypipes> that means I can have that done sooner than 2 hours.
14:35:53 <alex_xu> +1
14:35:55 * mriedem starts his stopwatch
14:36:03 <jaypipes> kthxbai
14:36:24 <cdent> so we have a good short term plan on that, yes?
14:36:26 <cdent> anything else?
14:36:47 <jaypipes> can https://bugs.launchpad.net/nova/+bug/1778591 be closed as Won't Fix then?
14:36:47 <openstack> Launchpad bug 1778591 in OpenStack Compute (nova) "GET /allocations/{uuid} on a consumer with no allocations provides no generation" [Medium,In progress] - Assigned to Jay Pipes (jaypipes)
14:36:54 <jaypipes> I think so but just checking
14:37:07 <jaypipes> (since no allocations means consumer should be deleted...)
14:37:11 <efried> jaypipes: please ping me direct for reviews on that stuff; right now they won't float to the top of my radar by themselves.
14:37:19 <jaypipes> ack
14:37:31 <cdent> jaypipes: yes, that one can go
14:37:33 <efried> jaypipes: Agree, close the bug, should be n/a once consumers are auto-deleted.
14:37:37 <jaypipes> ++
14:38:16 <jaypipes> done
14:38:25 <jaypipes> 1 down, eleventy billion to go.
14:38:49 <cdent> winning
14:38:50 <efried> NaN
14:39:09 <cdent> any other bugs people want to mention?
14:39:31 <jaypipes> does someone want to create a bug for the "delete consumers having no allocations" behaviour?
14:39:59 <efried> thought we had one.  If not, I nominate mriedem
14:40:04 <jaypipes> never mind, I'll do it...
14:40:15 <jaypipes> already have all these other bugs open in browser anyway
14:40:55 <mriedem> that sounds like bug 1779725 to me but i guess not
14:40:55 <openstack> bug 1779725 in OpenStack Compute (nova) "Auto-created consumer record not cleaned up after failed allocation" [Medium,In progress] https://launchpad.net/bugs/1779725 - Assigned to Jay Pipes (jaypipes)
14:41:22 <efried> no, that's https://review.openstack.org/#/c/579921/
14:41:25 <efried> different thing
14:41:55 <efried> That's the one dansmith is on the hook to approve.  (jaypipes, I can't tell at a glance, is tetsuro's -1 addressed?)
14:41:56 <mriedem> ok so what's that other thing?
14:42:11 <efried> mriedem: Automatically deleting consumers when their last allocation is deleted.
14:42:20 <mriedem> ah ok
14:42:29 <dansmith> efried: you just said you were workign through that series no?
14:42:49 <jaypipes> efried: I addressed tetsuro's comment. he missed that consumers were being deleted on line 489
14:42:58 <mriedem> jaypipes: cdent: i'm not aware of a bug for "Automatically deleting consumers when their last allocation is deleted" but it's lower priority too
14:42:59 <efried> dansmith: I hit the first one; I can hit that one too, but if you have room...
14:43:11 <jaypipes> efried, mriedem: ok, new bug for auto-delete consumers when last allocation deleted: https://bugs.launchpad.net/nova/+bug/1780799
14:43:11 <openstack> Launchpad bug 1780799 in OpenStack Compute (nova) "Consumers with no allocations should be auto-deleted" [High,Triaged]
14:43:21 <efried> ack
14:43:23 <dansmith> efried: okay but you said I'm "on the hook" for it which presumably means you specifically want me to see that one right?
14:43:31 <dansmith> or is there _another_ one you're talking about?
14:43:43 <efried> dansmith: That's the one.  Sorry for the confusion.  You or me?
14:44:16 <dansmith> I don't care
14:44:40 <efried> dansmith: You then, please.  My review cup runneth over.
14:44:48 <efried> Thanks.
14:45:05 <dansmith> heh, whereas my cup is so empty
14:45:16 * cdent pours dansmith a nice cold beer
14:45:31 * cdent beers all around
14:45:35 <efried> wheat, unfiltered, IIRC
14:45:36 * cdent group hugs
14:45:50 <mriedem> ok what's next
14:45:55 <cdent> any other bugs?
14:46:13 <cdent> #topic opens
14:46:22 <cdent> any random things people need to bring up?
14:46:26 <Jack1> Excuse me,I hava some questions.Can you tell me the PCI_DEVICE class 's roadmap in placement api?I see the placement api is only count the disk、memory、cpu and vgpu resource,but what about the other resource?
14:46:26 <Jack1> Does the PCI_DEVICE class is only mean passthrough gpu devices?
14:47:34 <efried> Jack1: That sounds like a Generic Device Manager thing.  I'm not aware of any immediate plans to start reporting/allocating PCI_DEVICE via placement.
14:47:43 <efried> Anyone else have a view on that?
14:47:59 <cdent> jaypipes ^ ?
14:48:12 <jaypipes> efried: yeah, it was originally intended as the passthrough device resource class.
14:48:46 <jaypipes> efried, cdent: but no virt driver (or external agent) that I'm aware of uses it (i.e. nothing creates inventory records for it)
14:48:49 <efried> FWIW, I'm starting to work that kind of thing in the nova-powervm (OOT) driver, hoping to propose it in-tree in Stein.
14:49:10 <efried> ...as the starting point / PoC / reference iml for GDM.
14:49:14 <efried> s/iml/impl/
14:49:16 <Jack1> Does the PCI_DEVICE class is only mean passthrough gpu devices?
14:49:25 <jaypipes> Jack1: it is not used yet.
14:49:26 <efried> Jack1: It doesn't mean anything at the moment, is what we're saying.
14:49:31 <Jack1> not include the LAN device?
14:49:58 <efried> Jack1: At the moment, if you want to do passthrough (of any PCI device) you still have to use the [pci]passthrough_whitelist etc.
14:50:00 <jaypipes> Jack1: do not use it.
14:50:41 <jaypipes> Jack1: in #openstack-placement after this meeting, come tell us about your use case and what you're trying to do, ok?
14:51:02 <Jack1> Oh,only to use compute node to achieve it?
14:51:06 <Jack1> ok
14:51:12 <Jack1> Thank you
14:51:27 <Jack1> when ?
14:51:45 <efried> As soon as we're done here.  Like now.
14:51:45 <jaypipes> Jack1: 10 minutes.
14:52:00 <Jack1> after 10 min?
14:52:16 <Jack1> ok
14:52:32 <cdent> Any other queries or comments for opens?
14:53:55 <cdent> Okay, I've got one: I'm going to need to rebalance my use of time a bit because of new obligations, so I'd like to drop being the interim runner of this meeting (and potentially attending at all). I assume that that's a better choice than dropping the weekly pupdates?
14:54:29 <cdent> Who can step up to run the meeting, if we feel it needs to continue?
14:54:51 <mriedem> i nominate efried
14:54:56 <efried> I'll do it.
14:55:00 <mriedem> huzzah
14:55:23 <efried> cdent: Sure would be nice if you could continue to attend, though.
14:56:18 <cdent> I'll try, but a) there's yet more on my plate these days and b) I'd really like to live up to the "go home at the end of the day, and let the other things lag" I wrote on https://anticdent.org/some-opinions-on-openstack.html
14:57:18 <cdent> In fact, efried, you'd be a good candidate for that paragraph. But thank you for letting yourself be volunteered.
14:57:56 <cdent> Anyone or anything else?
14:58:45 <efried> call it
14:58:59 <mriedem> heads
14:59:22 <cdent> #endmeeting