14:00:29 #startmeeting nova-scheduler 14:00:30 Meeting started Mon Feb 11 14:00:29 2019 UTC and is due to finish in 60 minutes. The chair is efried. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:33 The meeting name has been set to 'nova_scheduler' 14:00:37 o/ 14:00:38 o/ 14:00:42 o/ 14:00:42 \o 14:00:44 \o 14:00:47 \o 14:01:41 oh hai 14:02:30 Welcome one and all to the last n-sch meeting before the second full moon of 2019! 14:02:44 #link agenda https://wiki.openstack.org/wiki/Meetings/NovaScheduler#Agenda_for_next_meeting 14:02:57 #topic specs and review 14:03:02 oooo special 14:03:12 ikr 14:03:15 #link latest pupdate http://lists.openstack.org/pipermail/openstack-discuss/2019-January/002055.html 14:03:15 #link blueprint tracking https://etherpad.openstack.org/p/nova-stein-blueprint-status 14:03:45 #link libvirt reshaper https://review.openstack.org/#/c/599208/ 14:03:45 I saw some excitement in -nova just now about this. bauzas gibi anything worth sharing? 14:04:08 I think 14:04:08 efried: well, just discussing about reshapes 14:04:09 https://review.openstack.org/#/c/599208/ 14:04:13 i reckon a key thing here is that we're open for business on the placement releated specs and tetsuro has started on at least one of them 14:04:35 (cdent getting there) 14:04:41 gibi helped me identifying a possible issue with VGPU allocations unrelated to real mdevs 14:05:06 gibi to the rescue again. 14:05:07 (yea, I was typing that while you seemed to be waiting for something to happen, and then I realized where you were going, but decided I didn't want to store my buffer so flushed it) 14:05:23 gibi keeps doing that 14:05:36 :) 14:05:55 So bauzas we're expecting another respin soon? 14:06:03 tldr ^ ? 14:06:07 efried: yup, working on it 14:06:18 cool 14:06:19 #link xen reshaper (middle of series) https://review.openstack.org/#/c/521041 14:06:26 Assume still stalled, unless someone has an update 14:06:33 and when I say "working", I really mean 'I stopped to be paid by our customers' 14:07:04 customers schmustomers, *I* know what's best for Nova! 14:07:28 #link in_tree allocation candidates series starting at https://review.openstack.org/#/c/635722/ 14:07:30 tip: ibm will pay you either way 14:07:37 tetsuro has a good start on this --^ 14:08:04 tetsuro: anything we need to know about this? 14:08:19 (that isn't apparent from the spec/review?) 14:08:48 tetsuro might not actually be here. Moving on. 14:08:55 #topic Extraction 14:08:55 #link Extraction https://etherpad.openstack.org/p/placement-extract-stein-5 14:09:33 As cdent mentioned, key thing here is that we decided to 14:09:33 a) open extracted placement for business, viz aforementioned in_tree alloc cands patch from tetsuro 14:09:33 b) freeze in-tree placement, but keep it around for Stein 14:10:22 c) not write any nova code to use features developed in a), version discovery capabilities notwithstanding. 14:11:09 wrt b), we realized we had something of a testing hole (we weren't testing in-tree placement anymore) so mnaser is putting together a job to do that again. 14:11:10 * bauzas nods 14:11:44 #link CI job for in-tree placement with ansible https://review.openstack.org/#/c/635852/ 14:11:44 (I think) 14:12:03 yes that's it 14:12:18 with the NUMA/HPC/NFV firehose for Placement queries coming by at the PTG, I like the idea to start thinking about both testing *and* new features 14:12:32 ++ 14:12:45 cdent, edleafe: anything else about extraction to highlight? 14:12:59 No, that about covers it 14:13:03 aye 14:13:12 aye that covers it, or aye you have something else? 14:13:19 covers it 14:13:23 cool, moving on. 14:13:35 #topic bugs 14:13:35 #link Placement bugs https://bugs.launchpad.net/nova/+bugs?field.tag=placement 14:13:35 Any bugs to highlight? 14:14:03 ight 14:14:05 #topic opens 14:14:30 Anyone? 14:14:40 PTL election season is just around the corner 14:14:52 mm 14:14:55 It might be time to revisit the governance change 14:15:07 So that we don't need a special election 14:15:21 #link election details: https://review.openstack.org/#/c/629749/ 14:15:50 where are we on the checklist? A matter of merging the VGPU reshaper patch and proving upgrades with tripleo and/or osa? 14:15:50 so there is about 3 weeks to determine the governance change 14:16:17 seems like from what I heard from lyarwood, the upgrades deal was going to happen too late for ^ 14:16:21 yes 14:16:22 it is 14:16:28 which is why placement in-tree is staying for stein, 14:16:39 and the compromise was lifting the extracted placement api freeze in stein 14:16:41 that isn't the only reason 14:17:14 i think the governance checklist probably needs amending due to the change in plans for stein given the deployment tooling stuff 14:17:39 * cdent agrees 14:18:09 at this point i think we're just waiting on the reshaper thing 14:18:25 one way to look at it would be that, as long as we have an in-nova placement, placement should be governed under nova 14:18:25 but 14:18:25 the other way to look at it is that governance is about shaping the direction of placement, and since in-nova placement is frozen, that's n/a 14:18:25 so 14:18:25 I for one would be in favor of amending as stated. 14:18:30 deployment tools are targeting base install for stein with tripleo being "there" and OSA working on it 14:18:40 which is one of the reasons why I shifted gears recently to make sure I'm not blocking you 14:19:15 I just feel a bit uncomfortable to discuss governance change here and now 14:19:30 this timeslot isn't convenient for all parties 14:19:31 changing the governance helps to signal that the extracted things is _the_ thing, hopefully encouraging related projects to move along as needed 14:19:46 for any deployment tools that aren't working on supporting deploying extracted placement for stein, they should probably be kicked in the butt because they are going to be surprised in train when the in-tree nova code is dropped 14:20:09 The signaling to others is important, IMO 14:20:13 So we need to repoen this discussion with melwitt present, proposal being to have a placement PTL election with the rest, contingent upon VGPU reshaper being merged by the time campaigning starts? 14:20:14 bauzas: cdent did ask melwitt about this last week after the call 14:20:18 she said she'd think abou tit 14:20:19 *about it 14:20:23 ok 14:20:28 okay 14:20:44 yeah we want neither nova nor placement to have their progress gated forever on deployment tools 14:21:28 so is there an #action from here? 14:21:49 somebody following up with melwitt ? 14:21:50 looks like train PTL nominations are right after stein feature freeze 14:22:06 well, 14:22:22 could just post something to the ML for follow up discussion in the nova meeting this week 14:23:00 that said, I'm not sure about the fact that a new governance change will make deployment tools more committed 14:23:01 Let's check in with melwitt first 14:23:16 If she's a no, then it's kind of moot 14:23:19 edleafe: by post to the ML i meant post "this is an idea" 14:23:23 just to be clear, it's - I think - not a signaling problem, more a resources problem :) 14:23:38 mriedem: ++, as long as that won't be the first time she hears of it, which it sounds like it won't. 14:23:44 it's not 14:23:52 briefly discussed in -placement last week 14:23:58 right 14:24:05 bauzas: right, the goal isn't to signal encouragement, it is to avoid overly tight coupling, in the face of limited resources 14:24:18 bauzas: governance change won't speed up deployment tooling adoption of extracted placement, 14:24:23 but nova dropping the in-tree code in train will 14:24:29 oh yeah 14:24:43 or should 14:24:52 dangerous word "should"... 14:24:53 well, if you break, you loose 14:25:04 who has the ml action? edleafe or efried ? 14:25:16 I can do it 14:25:22 cool 14:25:26 I just feel most of the deployment team know about the story 14:25:39 i wouldn't assume that 14:25:50 e.g. chef and juju 14:25:54 don't know how active they are 14:25:56 "assume" also dangerous word 14:26:02 okay okay 14:26:04 but juju is financed so i'm sure they'll put resources on it 14:26:06 Thanks edleafe 14:26:06 #action edleafe to post to ML suggesting placement PTL election with the rest in the next cycle 14:26:47 Anything else before we close? 14:26:59 I just feel that if chef or juju isn't that active for knowing placement being splitted, then I guess they won't probably bother about a new PTL or even a code break until they run it :) 14:27:07 but meh 14:27:22 there's a reason there is a cycle-trailing release mode 14:27:35 It's a signal. It can be ignored. :) 14:28:34 As mriedem says, given the current strategy (in-nova freeze in stein, remove in train), governance changes should be pretty irrelevant for deployment 14:29:27 it's gonna be nova-net all over again! 14:29:37 i was already thinking that :) 14:29:40 and god i hope not 14:30:08 hell we haven't even dumped cells v1 yet 14:31:16 Ready to wrap up? 14:31:33 Thanks all 14:31:33 o/ 14:31:33 #endmeeting