13:00:45 <esberglu> #startmeeting powervm_driver_meeting
13:00:46 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:50 <openstack> The meeting name has been set to 'powervm_driver_meeting'
13:00:59 <edmondsw> o/
13:01:01 <efried> \o
13:01:25 <esberglu> #topic In-Tree Driver
13:01:40 <esberglu> Not much motion here in the last week
13:01:46 <esberglu> Config drive still up for review
13:02:04 <esberglu> I spent some time at the end of last week trying to get and OVS devstack run to work
13:02:13 <esberglu> Still working on that
13:02:24 <edmondsw> how's that going?
13:02:24 <esberglu> That's about it for me IT
13:02:40 <edmondsw> stuck, or making progress?
13:02:58 <esberglu> edmondsw: I got an OOT stack working with OVS, but haven't tried the equivalent IT yet
13:03:08 <edmondsw> k, cool
13:03:10 <esberglu> Figured I should be able to base most of it on that
13:03:33 <edmondsw> I keep getting distracted when I go to review the config drive patch
13:04:10 <edmondsw> efried once I review that, you think we can start asking for reviews in the community, or.. ?
13:04:41 <edmondsw> should we have thorst review first?
13:04:56 <efried> Nah, we should be able to ask sdague
13:05:14 <edmondsw> k, I'll try to look at that today
13:05:23 <esberglu> edmondsw: sweet
13:05:32 <edmondsw> #action edmondsw to review IT config drive patch
13:05:52 <edmondsw> that's probably all for IT then
13:05:59 <esberglu> #topic Out-of-Tree Driver
13:06:19 <esberglu> I spent a little time yesterday afternoon working on porting the host cpu stats to pypowervm
13:06:40 <esberglu> Got the UT working, but the 1st try is failing sonar
13:07:02 <efried> whee
13:07:09 <esberglu> edmondsw: You said we need that by next week?
13:07:17 <edmondsw> sounds like a good start, though. Can't ever expect sonar to work first time ;)
13:07:25 <edmondsw> yeah
13:07:59 <edmondsw> let's try to finish it this week if we can
13:08:27 <esberglu> edmondsw: Yep I'll finish it this week to leave time for reviews
13:09:05 <edmondsw> mdrabe efried should we talk about the DefaultStandardize change?
13:09:15 <efried> mdrabe not here?
13:09:17 <edmondsw> mdrabe you here?
13:09:24 <edmondsw> oh nope...
13:09:55 <efried> I can summarize the issue, if you like.
13:10:13 <efried> 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 <edmondsw> I've been following along, just wanted to discuss next steps
13:10:38 <efried> So if you use DefaultStandardize, you'll always blat the values in its init with the defaults.
13:10:49 <efried> Including max_io_slots
13:11:24 <efried> 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 <edmondsw> what I didn't quite follow was why there were two values we have to pick between which to keep...
13:12:53 <edmondsw> one from the wrapper, and another from slot_mgr
13:12:58 <edmondsw> can you explain that?
13:13:19 <edmondsw> I think you guys agreed to always keep whichever of the 2 was higher
13:14:16 <efried> 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 <edmondsw> 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 <efried> I believe the slot manager figures out the highest slot being used by the source.
13:16:11 <efried> 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 <efried> 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 <efried> 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 <edmondsw> ok, so it's all about that issue with 1.1.7
13:18:12 <efried> 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 <efried> No, not entirely.
13:18:24 <efried> The resize issue was still a bug, even before 1.1.7
13:18:44 <edmondsw> oh, true
13:18:52 <efried> 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 <efried> 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 <efried> 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 <edmondsw> 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 <efried> No, actually.
13:21:57 <efried> If both of those things are in play for some reason, we should choose the highest.
13:22:06 <edmondsw> k
13:22:15 <edmondsw> I think that makes sense
13:22:34 <edmondsw> will want some nice comments about that in the code
13:22:40 <edmondsw> explaining why
13:22:49 <efried> Cause there's some semantic like "cold migrate resize" in play.
13:23:08 <efried> or maybe it's "live resize with migration"
13:23:13 <efried> Saw a bp go by about that.
13:23:18 <edmondsw> ok, probably enough time on that
13:23:24 <edmondsw> tx for the explanation
13:23:37 <edmondsw> the only other thing I know of going on OOT is the iscsi work
13:23:37 <efried> yuh, moving on.
13:23:49 <edmondsw> we've been making progress there
13:24:09 <edmondsw> tjakobs has been working to address comments
13:24:21 <edmondsw> that's probably all for OOT
13:24:52 <esberglu> #topic Device Passthrough
13:25:41 <edmondsw> efried you're up
13:25:51 <efried> Still waiting for jwcroppe to come back on requirements.
13:26:04 <efried> I started trying to stack that new system, as time has allowed.
13:26:13 <efried> Haven't succeeded yet, I don't think.
13:26:28 <efried> But otherwise, nothing to report on the pre-Queens-hackup version.
13:27:00 <efried> 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 <edmondsw> efried I didn't realize you were still waiting for input from jwcroppe. Are you sure he knows that?
13:27:20 <efried> yeah
13:27:29 <efried> You guys were gonna review my spec on granular resource request syntax, remember?
13:27:33 <efried> https://review.openstack.org/#/c/510244/
13:27:35 <edmondsw> that's good news about queens
13:27:54 <edmondsw> yeah, I remember...
13:27:57 <esberglu> efried: I will today
13:28:16 <edmondsw> #action edmondsw and esberglu to review https://review.openstack.org/#/c/510244/
13:28:54 <efried> Note that spec freeze is Thursday, so don't -1 me for typos.
13:28:59 <efried> just for substantive stuff.
13:29:24 <edmondsw> ack
13:29:57 <esberglu> Yep Queens-1 thursday, forgot to say that during the drivers bit thanks
13:30:33 <esberglu> efried: Anything else before we move on?
13:30:43 <efried> Jay is on vacation
13:30:52 <edmondsw> Jay is changing companies
13:30:55 <efried> And I volunteered to babysit his NRP seres while he's gone.
13:30:57 <efried> Yes
13:31:22 <edmondsw> cool
13:32:08 <edmondsw> alright... CI?
13:32:09 <esberglu> #topic PowerVM CI
13:32:36 <esberglu> Need to check with nvcastet today on that bug we've been seeing in CI
13:32:56 <edmondsw> hsien should also be back now
13:33:18 <esberglu> Other than that mostly just backlog items as able, nothing too exciting
13:34:34 <esberglu> #topic Open Discussion
13:34:48 <edmondsw> nothing more from me
13:35:04 <esberglu> neither
13:35:55 <esberglu> #endmeeting