13:00:45 #startmeeting powervm_driver_meeting 13:00:46 Meeting started Tue Oct 17 13:00:45 2017 UTC and is due to finish in 60 minutes. The chair is esberglu. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:50 The meeting name has been set to 'powervm_driver_meeting' 13:00:59 o/ 13:01:01 \o 13:01:25 #topic In-Tree Driver 13:01:40 Not much motion here in the last week 13:01:46 Config drive still up for review 13:02:04 I spent some time at the end of last week trying to get and OVS devstack run to work 13:02:13 Still working on that 13:02:24 how's that going? 13:02:24 That's about it for me IT 13:02:40 stuck, or making progress? 13:02:58 edmondsw: I got an OOT stack working with OVS, but haven't tried the equivalent IT yet 13:03:08 k, cool 13:03:10 Figured I should be able to base most of it on that 13:03:33 I keep getting distracted when I go to review the config drive patch 13:04:10 efried once I review that, you think we can start asking for reviews in the community, or.. ? 13:04:41 should we have thorst review first? 13:04:56 Nah, we should be able to ask sdague 13:05:14 k, I'll try to look at that today 13:05:23 edmondsw: sweet 13:05:32 #action edmondsw to review IT config drive patch 13:05:52 that's probably all for IT then 13:05:59 #topic Out-of-Tree Driver 13:06:19 I spent a little time yesterday afternoon working on porting the host cpu stats to pypowervm 13:06:40 Got the UT working, but the 1st try is failing sonar 13:07:02 whee 13:07:09 edmondsw: You said we need that by next week? 13:07:17 sounds like a good start, though. Can't ever expect sonar to work first time ;) 13:07:25 yeah 13:07:59 let's try to finish it this week if we can 13:08:27 edmondsw: Yep I'll finish it this week to leave time for reviews 13:09:05 mdrabe efried should we talk about the DefaultStandardize change? 13:09:15 mdrabe not here? 13:09:17 mdrabe you here? 13:09:24 oh nope... 13:09:55 I can summarize the issue, if you like. 13:10:13 The way lpar_builder is set up, it can't actually tell if it's creating a new LPAR or updating an existing one. 13:10:14 I've been following along, just wanted to discuss next steps 13:10:38 So if you use DefaultStandardize, you'll always blat the values in its init with the defaults. 13:10:49 Including max_io_slots 13:11:24 So this change set is detecting when we have an existing LPAR and overwriting the DefaultStandardize values with the existing values from the wrapper. Which is stupid. But is actually the least evil AFAICT. 13:11:25 what I didn't quite follow was why there were two values we have to pick between which to keep... 13:12:53 one from the wrapper, and another from slot_mgr 13:12:58 can you explain that? 13:13:19 I think you guys agreed to always keep whichever of the 2 was higher 13:14:16 It's possibly because this was a problem before, but we were in such a rush to implement the damned slot manager stuff, we just went with the first solution we came up with. 13:15:23 how could the slot_mgr have a value that's more correct about the current state of the VM than the lpar wrapper? 13:15:26 I believe the slot manager figures out the highest slot being used by the source. 13:16:11 Oh, because if the original LPAR was created with a non-default slot limit - which would have been possible before I introduced that bug - then you could have wound up using a slot higher than the default max (64). 13:16:37 Then when you went to rebuild, it would rebuild the new LPAR with the default (64) and try to put a mapping on the >64 slot - kaboom. 13:17:01 Oh, yeah, so it's not actually a horrible patchup solution. Because on a RR, we're creating the target LPAR afresh. 13:17:56 ok, so it's all about that issue with 1.1.7 13:18:12 So anyway, on a RR, we want to use whatever the slot manager said (which in fact is probably whatever was on the source LPAR, not just arbitrarily the highest); but on a resize we want to use whatever the original LPAR had. 13:18:16 No, not entirely. 13:18:24 The resize issue was still a bug, even before 1.1.7 13:18:44 oh, true 13:18:52 Try to resize an LPAR that started off with a nonstandard max_io_slots (or in fact any of those other fields DefaultStandardize defaults), and you'll end up with the defaults in those fields. 13:19:58 I'm actually not completely sure there'll ever *be* a scenario where we'll have *both* a source LPAR and a slot manager. 13:20:31 So in fact the "choose the highest" thing might be moot. For now. But better to do it and have it be a no-op than to have to track down THAT bug later on. 13:21:23 it sounded like you said instead of "choose highest" you're now thinking we should choose one or the other based on resize vs. RR 13:21:44 No, actually. 13:21:57 If both of those things are in play for some reason, we should choose the highest. 13:22:06 k 13:22:15 I think that makes sense 13:22:34 will want some nice comments about that in the code 13:22:40 explaining why 13:22:49 Cause there's some semantic like "cold migrate resize" in play. 13:23:08 or maybe it's "live resize with migration" 13:23:13 Saw a bp go by about that. 13:23:18 ok, probably enough time on that 13:23:24 tx for the explanation 13:23:37 the only other thing I know of going on OOT is the iscsi work 13:23:37 yuh, moving on. 13:23:49 we've been making progress there 13:24:09 tjakobs has been working to address comments 13:24:21 that's probably all for OOT 13:24:52 #topic Device Passthrough 13:25:41 efried you're up 13:25:51 Still waiting for jwcroppe to come back on requirements. 13:26:04 I started trying to stack that new system, as time has allowed. 13:26:13 Haven't succeeded yet, I don't think. 13:26:28 But otherwise, nothing to report on the pre-Queens-hackup version. 13:27:00 The Queens stuff is going fairly well, though. It's possible we could be able to do everything we need with generic RPs on a Queens base. 13:27:14 efried I didn't realize you were still waiting for input from jwcroppe. Are you sure he knows that? 13:27:20 yeah 13:27:29 You guys were gonna review my spec on granular resource request syntax, remember? 13:27:33 https://review.openstack.org/#/c/510244/ 13:27:35 that's good news about queens 13:27:54 yeah, I remember... 13:27:57 efried: I will today 13:28:16 #action edmondsw and esberglu to review https://review.openstack.org/#/c/510244/ 13:28:54 Note that spec freeze is Thursday, so don't -1 me for typos. 13:28:59 just for substantive stuff. 13:29:24 ack 13:29:57 Yep Queens-1 thursday, forgot to say that during the drivers bit thanks 13:30:33 efried: Anything else before we move on? 13:30:43 Jay is on vacation 13:30:52 Jay is changing companies 13:30:55 And I volunteered to babysit his NRP seres while he's gone. 13:30:57 Yes 13:31:22 cool 13:32:08 alright... CI? 13:32:09 #topic PowerVM CI 13:32:36 Need to check with nvcastet today on that bug we've been seeing in CI 13:32:56 hsien should also be back now 13:33:18 Other than that mostly just backlog items as able, nothing too exciting 13:34:34 #topic Open Discussion 13:34:48 nothing more from me 13:35:04 neither 13:35:55 #endmeeting