14:00:03 #startmeeting nova_scheduler 14:00:04 Meeting started Mon Jul 23 14:00:03 2018 UTC and is due to finish in 60 minutes. The chair is efried. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:07 The meeting name has been set to 'nova_scheduler' 14:00:12 o\ 14:00:12 o/ 14:00:29 hello folks 14:00:30 o/ 14:00:38 (back from sick days) 14:00:51 o/ 14:01:06 o/ 14:01:25 #link agenda https://wiki.openstack.org/wiki/Meetings/NovaScheduler#Agenda_for_next_meeting 14:01:42 #topic last meeting 14:01:48 o/ 14:01:50 #link last minutes: http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-07-16-13.59.html 14:01:57 Any old business? 14:02:19 o/ (kinda) 14:02:33 #topic specs and review 14:03:03 #link latest pupdate: http://lists.openstack.org/pipermail/openstack-dev/2018-July/132387.html 14:03:20 Comments, questions, concerns, or other feedback on the pupdate? 14:04:01 #link reshaper series: https://review.openstack.org/#/q/topic:bp/reshape-provider-tree+status:open 14:04:16 * mriedem hasn't read it yet 14:04:40 cdent and gibi co-discovered a bug this morning: 14:04:42 #link IndexError when clearing a provider's inventories: https://bugs.launchpad.net/nova/+bug/1783130 14:04:42 ...on the bottom patch, which is already gateward. 14:04:42 Launchpad bug 1783130 in OpenStack Compute (nova) "placement reshaper doesn't clear all inventories for a resource provider" [Medium,Confirmed] - Assigned to Eric Fried (efried) 14:04:59 But since we're not consuming the thing yet, it's not worth yanking it out of the gate. I'm going to work a fix after this meeting. 14:05:56 the reshaper api change is approved? 14:06:03 No 14:06:06 just the db side 14:06:14 so https://review.openstack.org/#/c/582383/ 14:06:20 yes 14:06:24 The API change is the second patch 14:06:24 #link reshaper handler & microversion https://review.openstack.org/#/c/576927/ 14:06:30 and the regression is *just* for the reshaper flow? 14:06:35 I'll try to review those 14:06:46 mriedem: yes, it's not a regression, just a bug in the new code. 14:06:50 ok 14:07:02 The API patch (above) is still running afoul of https://bugs.launchpad.net/nova/+bug/1782340 14:07:02 Launchpad bug 1782340 in OpenStack Compute (nova) "allocation schema does not set additionalProperties False in all the right places" [Medium,In progress] - Assigned to Chris Dent (cdent) 14:07:11 Which we need to discuss here. 14:07:36 openstack: cdent has proposed a 14:07:36 #link "just fix it" fix for bug 1782340: https://review.openstack.org/#/c/583907/ 14:07:42 that was weird 14:08:08 anyway, we need to decide whether it's acceptable to break the rules and just fix it, or insist on a microversion. 14:08:11 how far along are the nova compute side bits to consume reshaper at this point? 14:08:34 mriedem: Will get to that in after we discuss --^ 14:08:43 mriedem: good question 14:08:44 s/in// 14:08:54 mriedem: that's why I need to review the series 14:09:00 to know how to consume it 14:09:09 but not for this cycle 14:09:21 I expressed my opinion in the review. By the rules, we need a microversion. But we should break the rules and not do one. 14:10:02 efried: that's the majority opinion, so if majority rules, we're good to go 14:10:04 i hedged on the bug report https://bugs.launchpad.net/nova/+bug/1782340/comments/8 14:10:04 Launchpad bug 1782340 in OpenStack Compute (nova) "allocation schema does not set additionalProperties False in all the right places" [Medium,In progress] - Assigned to Chris Dent (cdent) 14:10:33 i won't fight against just fixing this w/o a microversion if that helps 14:10:39 Good enough for me. So let's get a second core to +A that sucker and get the series moving. 14:11:16 cdent: wait, is that the bug that's blocking the reshaper API patch? 14:12:05 jaypipes: Can you see well enough to push that patch? It's just 16LOC and very simple. 14:12:30 efried: yes, I didn't base it into the tree because stuff was too in-flight. I figured I'd wait until jay's thing merges 14:12:44 or just let it merge all on its lonesome 14:13:15 wfm. I'm going to need to take over the pile to fix the IndexError bug, so I'll do whatever rebase shuffling is necessary at that time. 14:13:50 gibi: Maybe you want to save jaypipes's eyeballs and push https://review.openstack.org/#/c/583907/ for us? 14:13:53 we can find the cores after the meeting to deal with it, let's let jaypipes heal a bit 14:14:00 efried: done 14:14:04 Thanks jaypipes 14:14:12 moving onward. 14:14:17 efried: ack 14:14:22 efried: I'll push up my pending code on /reshaper after we're done here, and then be hands off for the rest of my day 14:14:24 gibi: cancel, jaypipes got it. 14:14:29 :) 14:14:32 cdent: what do you have pending? 14:14:33 * jaypipes goes to make a homemade eyepatch. yarr. 14:14:47 efried: the test that found the bug and... 14:15:06 fixes as suggested by gibi 14:15:21 (which is moving a thing inside the nested exception) 14:15:39 and your suggestion about an improved debug message 14:16:00 Okay, the client side: 14:16:00 #link client side cumulative patch https://review.openstack.org/#/c/576236/ 14:16:08 jaypipes: I require that you go out on a boat. Even only briefly 14:16:16 To answer mriedem, ^ has all the code side written, but no tests yet. 14:16:44 That patch is already big, so as I started writing tests, I started breaking it up into smaller pieces for ease of review. 14:17:20 Those start here: 14:17:21 #link bottom of the new-and-improved reshaper client side series https://review.openstack.org/#/c/584598/ 14:17:51 It's still pretty early days, but that's my main focus from now until it's done. 14:18:20 ok, can we agree to hold off on merging the reshaper api change until we have a good pass on the client side changes? 14:18:25 That cumulative patch will be either abandoned or drastically trimmed to comprise some part of that series, but if you want to look at it now to get an overview of how things are gonna work, it's there. 14:18:54 mriedem: That's a fair idea. I'll -2... 14:19:33 ...done. 14:19:39 mriedem: that was the original idea on the back end too, but we ... forgot basically 14:19:51 The back end is not a big deal. 14:19:59 we can keep fixing that 14:20:08 We just don't want to burn a microversion if we can help it. 14:20:26 * cdent knows 14:20:36 cdent: as long as the backend was a new thing and not a big refactor/merge of existing functionality, then that's fine 14:20:41 that's why i was worried about a regression 14:21:13 mriedem: Yup, good call. It is (a totally new thing). 14:21:30 Anything else for reviews? 14:21:45 Any non-reshaper specs/reviews anyone wants to bring up? 14:22:01 oh, here, lemme make the minutes prettier: 14:22:37 #agreed to "just fix" https://bugs.launchpad.net/nova/+bug/1782340 via https://review.openstack.org/#/c/583907/ without a microversion. 14:22:37 Launchpad bug 1782340 in OpenStack Compute (nova) "allocation schema does not set additionalProperties False in all the right places" [Medium,In progress] - Assigned to Chris Dent (cdent) 14:23:19 #agreed to put a procedural hold on the reshaper API change https://review.openstack.org/#/c/576927/ until the client side matures, so we don't burn a microversion. 14:24:37 #agreed no need to pull the db side reshaper patch https://review.openstack.org/#/c/582383/ out of the gate for https://bugs.launchpad.net/nova/+bug/1783130 since it's all new code, no regressions in existing. 14:24:37 Launchpad bug 1783130 in OpenStack Compute (nova) "placement reshaper doesn't clear all inventories for a resource provider" [Medium,Confirmed] - Assigned to Eric Fried (efried) 14:24:42 Moving on. 14:24:50 #topic bugs 14:24:55 #link placement bugs: https://bugs.launchpad.net/nova/+bugs?field.tag=placement&orderby=-id 14:25:34 Anyone have anything specific to discuss on bugs? 14:26:05 #topic opens 14:26:21 Planning/Doing support in nova/report client for: 14:26:21 #link consumer generation handling (gibi): https://review.openstack.org/#/c/583667/ 14:26:41 This is getting active work/review. 14:27:03 nested and shared providers for initial allocations 14:27:03 nested and shared providers when modifying migration (and other?) allocations 14:27:03 These haven't been started afaik 14:27:25 whatever else is not being remembered right now <== anyone have anything specific we can add to the list? 14:27:59 next up 14:28:01 os-resource-classes alternative: 14:28:12 #link library spike: https://github.com/cdent/os-resource-classes 14:28:12 #link placement integration spike: https://review.openstack.org/#/c/584084/ 14:28:39 cdent and I discussed some of this over the weekend via reviews on both of those. 14:28:44 what I'm after with those is "shall I carry on or is that not a good way to go?" 14:29:37 What's really needed at this point is a discussion including both cdent and jaypipes to figure out which way (or some other option not yet proposed) we want to go on os-resource-classes, so we can move forward. 14:30:03 that's probably ptg fodder at this point yeah? 14:30:15 https://etherpad.openstack.org/p/nova-ptg-stein 14:30:17 #link jaypipes' os-resource-classes proposal: https://github.com/jaypipes/os-resource-classes 14:30:17 throw it on the big board 14:30:27 omg, that's like _years_ away 14:30:30 :D 14:30:34 I read "pig fodder". I need *my* eyes checked. 14:32:27 Okay, I added it to the etherpad. But I kinda hope we can discuss it before then. As cdent notes, the ptg is a ways off, and it would be nice to get this done soonish so we can focus on other, harder extraction topics in Denver. 14:32:53 sure, 14:32:56 my point is, 14:33:12 we need to focus this week and avoid any noise on stuff that's not going to happen in rocky 14:33:26 point taken 14:33:38 speaking of "harder extraction topics". Whatever they are, can people add those to etherpad too (line 36-ish) 14:33:59 (probably something slightly less than 36) 14:35:15 Okay, any other topics for open discussion? 14:35:44 3 14:35:49 2 14:35:50 i need review 14:35:57 on sync_aggregates https://review.openstack.org/#/c/575912/ 14:36:01 to close out that bp 14:36:20 #link Add nova-manage placement sync_aggregates https://review.openstack.org/#/c/575912/ 14:36:28 at this point i think with efried's changes to how aggregate generation and conflicts are handled in report client i could probably re-use that code in the report client for this change, 14:36:35 but i'm not sure i'll have time to re-write this in time for FF 14:36:52 so i'm proposing we defer the refactor, get this in for FF and then i can refactor later 14:37:01 mriedem: again, I'm slowly returing full steam 14:37:09 mriedem: ping me for your sync_aggs serie 14:37:16 bauzas: ok, consider yourself pinged then 14:37:19 I'll take a look at it mriedem. If I can see a path to refactor, would you be amenable to me doing it? 14:37:27 * bauzas opening a tab then 14:37:42 efried: then you probably can't +2 it 14:37:49 and with it taking a week to merge code... 14:38:03 efried: your +2 is more valuable at this point 14:38:22 okay, it's on my radar anyway. 14:38:26 to review 14:38:36 i have a TODO in there for handling generatoin conflicts, 14:38:41 so there is a marker to eventually clean that up 14:39:05 I've got a series of patches that splits out the resource_provider.py object file for placement into multiple files. been waiting to push it until the reshape stuff is cleared. 14:39:17 ++ love that idea. 14:39:34 that file is >4KLOC 14:39:38 jaypipes: given FF is next week, probably a good idea to wait next week ;) 14:39:49 yeah, that's a thing that can totally be done after FF. 14:39:56 or people would scream about merge conflicts :p 14:40:42 bauzas: it's this week 14:40:44 thursday 14:40:48 oh shit 14:41:04 bauzas: and it's taking about a week to merge code right now 14:41:07 that's what happens when you have 2 weeks off 14:41:20 yeesh, wir haben sehr viel zu tun 14:42:06 okay, so unless there's anything else, let's go make code happen 14:42:23 #endmeeting