14:02:24 <edmondsw> #startmeeting PowerVM Driver Meeting
14:02:25 <openstack> Meeting started Tue Apr 17 14:02:24 2018 UTC and is due to finish in 60 minutes.  The chair is edmondsw. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:29 <openstack> The meeting name has been set to 'powervm_driver_meeting'
14:02:42 <edmondsw> #link https://etherpad.openstack.org/p/powervm_driver_meeting_agenda
14:03:28 <edmondsw> efried esberglu ut?
14:03:40 <esberglu> yep
14:03:49 <efried> ō/
14:03:51 <edmondsw> #topic In-Tree Driver
14:03:54 <edmondsw> #link https://etherpad.openstack.org/p/powervm-in-tree-todos
14:04:05 <edmondsw> I understand we're in a runway now
14:04:18 <edmondsw> excited to see how that goes
14:04:20 <efried> https://etherpad.openstack.org/p/nova-runways-rocky
14:04:20 <esberglu> Everything through localdisk is +1 from edmondsw, +2 from efried, and in the runway
14:04:40 <edmondsw> any comments yet?
14:05:06 <efried> nope
14:05:09 <efried> (just checked)
14:05:10 <esberglu> Nope. Target date for that is 4/30 so I'm expecting them to start coming in soon
14:05:34 <edmondsw> anything else to note here then?
14:05:34 <efried> We've been doing runways for all of two weeks, but tbh I haven't really noticed it prompting a significant increase in reviewer focus.
14:05:58 <efried> I'm thinking of suggesting a "champion" idea
14:06:14 <edmondsw> efried what would that be?
14:06:14 <esberglu> I've been prioritizing multinode CI over finishing the cold mig/resize patch, nothing to report there
14:06:31 <edmondsw> esberglu that makes sense... CI is a prereq for that
14:06:41 <efried> where we assign one reviewer (core or not, I guess, but not the owner of the series) to go pester reviewers to look at the changes, and pester the owner to follow up as needed.
14:07:06 <efried> kinda like we champion invention disclosures on IDTs.
14:07:13 <edmondsw> who pesters folks to be a champion? ;)
14:07:29 <efried> Touché
14:07:42 <efried> Part of the process; add it to runway, assign champion at that time.
14:07:50 <efried> just an idea I'm toying with.
14:08:00 <edmondsw> yep, I think that can work
14:08:13 <edmondsw> can become a nova meeting agenda item
14:08:52 <edmondsw> #topic Out-of-Tree Driver
14:09:03 <edmondsw> #link https://etherpad.openstack.org/p/powervm-oot-todos
14:09:16 <edmondsw> we've made some progress on the iscsi changes
14:09:41 <edmondsw> I just merged one, which put the others into merge conflict since they're not in a series
14:10:00 <edmondsw> I told prashkre to rebase the other that I +2/+A'd and when he does that I'll fast approve it
14:10:30 <edmondsw> I did give him a comment to go address on the 3rd iscsi commit
14:10:49 <edmondsw> he's off and running on that
14:11:10 <edmondsw> once those all merge, I intend to tag 6.0.1
14:11:11 <openstackgerrit> prashkre proposed openstack/nova-powervm master: Return iSCSI Initiator for VIOSes  https://review.openstack.org/557800
14:11:52 <edmondsw> I also just setup a meeting with the PowerVC storage guys to talk about community contribution for multiple initiator support, among other things
14:12:08 <edmondsw> anything else to discuss around iscsi?
14:12:45 <edmondsw> the volume refactor will need to be rebased and updated once these changes merge
14:13:02 <edmondsw> and I still need to dig into the concerns that the PowerVC team raised on that
14:13:16 <edmondsw> so probably more updates there
14:13:25 <edmondsw> tjakobs FYI ^
14:13:36 <edmondsw> anything else for OOT?
14:14:17 <edmondsw> some other things need to happen, like adding MSP support, but I haven't gotten to anything there
14:14:23 <efried> We could have done the iscsi changes in a series and not had to rebase.
14:14:38 <edmondsw> efried I suggested that a couple times, but nobody did it, so...
14:14:50 <efried> Not sure how much more prashkre is going to be doing for us, but might be worth a little tutorial on that.
14:15:27 <edmondsw> efried I'd love to see something written up on that for some wiki somewhere
14:15:34 <edmondsw> and then just link it with things like that
14:15:37 <efried> I'm sure there are documents galore.
14:15:46 <edmondsw> I'm sure... question is where, and how good are they
14:15:50 <efried> There's a whole man page for git restack
14:15:55 <efried> which is what I use *daily*
14:16:04 <edmondsw> if we find a good one, great, just need to keep in our back pocket and start linking
14:16:47 <edmondsw> maybe just link that then
14:16:58 <edmondsw> I'm familiar with rebase, but not restack
14:17:19 <edmondsw> which is probably why I'm confused about managing series myself
14:18:05 <efried> esberglu said he tried restack and couldn't get the hang of it.
14:18:19 <efried> but I love it.
14:18:32 <edmondsw> you play with it enough to figure out the quirks, probably
14:18:38 <esberglu> efried: I think it's because I didn't check out the latest patch. I would check out the latest in the series, git restack
14:18:48 <esberglu> Then change anything I want to edit to edit
14:18:54 <esberglu> And go from there?
14:19:20 <efried> yes, using git rebase --continue whenever you're ready to move to the next one up.
14:19:38 <esberglu> Okay I see where I went wrong now, thanks
14:19:49 <efried> But yeah, it's key to check out the top patch in the series.
14:20:06 <edmondsw> top = the first one that should merge?
14:20:13 <edmondsw> or is that bottom?
14:20:22 <esberglu> Top = last one that should merge
14:20:45 <efried> ^
14:21:00 <edmondsw> ok, so if I want to change something 3 patches down...
14:21:11 <edmondsw> I check out the top, and then what?
14:22:02 <efried> git restack
14:22:08 <efried> it puts you into an editor just like git rebase -i
14:22:20 <efried> You change 'pick' to 'edit' for any patches in the series you want to change.
14:22:36 <efried> Save/quit.  You'll be shoved down the chain into the first 'edit' patch.
14:22:45 <edmondsw> cool
14:23:04 <efried> Make your changes, and run git rebase --continue.  It'll commit your changes and put you into the commit message editor.
14:23:17 <efried> Save/quit that guy and you'll be shunted to the next 'edit' patch...
14:23:23 <efried> ...unless there's a merge conflict with one in between
14:23:29 <efried> in which case regular merge conflict process
14:23:32 <edmondsw> so you don't need to 'git commit' at all, it does that for you with rebase --continue?
14:23:33 <efried> when done, git rebase --continue.
14:23:45 <efried> yes.  You can do the commit yourself if you like
14:23:48 <edmondsw> just need to git add after you change something, and then rebase --continue?
14:23:57 <efried> either way.
14:24:05 <edmondsw> cool, got it
14:24:13 <edmondsw> moving on
14:24:15 <efried> note that it doesn't come in the box.
14:24:19 <efried> you have to pip install git-restack
14:24:25 <efried> it's something the os infra folks wrote, I think.
14:24:26 <edmondsw> oh, good to now
14:24:35 <edmondsw> #topic Device Passthrough
14:24:44 <edmondsw> efried what's the latest?
14:24:57 <efried> Jay and I had a knock-down drag-out; now we're asking for an impartial referee to decide who wins.
14:25:13 <edmondsw> you couldn't take him?
14:25:17 <edmondsw> ;)
14:25:33 <efried> So many possible responses to that.
14:25:42 <edmondsw> I was trying to set you up easy...
14:25:54 <efried> At this point I would be content either way tbh.  We've wrangled both of our proposals into compromise territory.
14:26:37 <efried> I still have a preference for mine, but I won't be seriously mad if it goes the other way.
14:26:45 <edmondsw> k
14:26:48 <efried> I made progress on the granular patch.
14:27:04 <efried> I've got the bugs worked out to where it has parity with the existing functionality
14:27:19 <efried> That is, if you're not using granular syntax, all the old scenarios still work when they're funneled through the new algorithm.
14:27:29 <efried> I'll be in microversion rebase hell until it merges.
14:27:53 <efried> Next step will be to write tests; and once the above argument is settled, to fold in that functionality.
14:28:01 <efried> Because it's looking likely that we're going to want to do it in the same microversion.
14:28:11 <efried> Jay admonished me for not waiting until his NRP stuff was done
14:28:16 <efried> and then started working on it again
14:28:21 <efried> Which was kind of the goal.
14:28:24 <edmondsw> :)
14:28:26 <efried> so goodness there.
14:28:58 <efried> So progress is being made overall.  Otherwise, nothing new to report specifically on device passthrough as it pertains to PowerVM.
14:29:13 <efried> oh
14:29:21 <efried> except I don't remember if I mentioned this
14:29:44 <efried> I wrote a couple of patches that use upt in libvirt to solve the age-old problem of sharing providers being double-reported.
14:30:03 <efried> I wouldn't have done it, except they took like 15 minutes and basically validated everything I wrote last cycle.
14:30:34 <efried> bhagyshris is going to take over the patches to fix up the tests and get everything ready to merge.
14:30:42 <edmondsw> cool
14:30:50 <efried> https://review.openstack.org/560444
14:30:50 <efried> https://review.openstack.org/560459
14:30:52 <edmondsw> I'm sure the KVM folks thank you
14:30:57 <efried> we'll see :)
14:31:27 <efried> I think that's all I have for now.
14:31:45 <edmondsw> I'm more than happy to see things fixed for libvirt, since Power cares about that as well as PowerVM
14:32:02 <edmondsw> one thing I was going to mention
14:32:53 <edmondsw> I think we've said before that we need to consider infiniband and other types of passthrough as well as GPU
14:33:07 <edmondsw> RoCE is another
14:33:49 <edmondsw> and more than just passthrough, virtualization like (or using, I hope) SR-IOV
14:34:00 <efried> We're getting set up for allll of that.
14:34:04 <edmondsw> except that I want to do it the right way, not the way we currently do SR-IOV
14:34:15 <edmondsw> so just throwing that out there... stay tuned
14:34:19 <edmondsw> yep yep
14:34:41 <edmondsw> #topic PowerVM CI
14:34:51 <edmondsw> #link https://etherpad.openstack.org/p/powervm_ci_todos
14:34:53 <edmondsw> esberglu ?
14:35:30 <esberglu> I've got a change out for the powervm-ci side of multinode. Just adds local.conf files and updates prep_devstack.sh to work with AIO, control, and compute cases
14:35:30 <esberglu> 6470
14:35:58 <esberglu> It doesn't affect any existing jobs so I'm ready to merge if you guys are okay with it, will make neo-os-ci dev easier to have that in
14:36:19 <edmondsw> esberglu ack
14:36:36 <efried> We gonna get Mujahid in here moving forward?
14:36:57 <esberglu> On neo-os-ci I've got to the point where I can have the control node stack, then kick off another job to have the compute stack
14:37:10 <edmondsw> efried yeah, I'll ask him to join, though I expect we'll have more CI discussions in slack going forward
14:37:25 <efried> ight
14:37:33 <esberglu> Still not sure what I have to do to force them to be on the same host, but staging CI only has 1 compute node right now
14:38:08 <esberglu> I want to bring neo4 back into staging, but I still have that set up for IT work, and might need it again there
14:38:25 <esberglu> I may just steal a node from production for a little while
14:38:36 <edmondsw> esberglu have you asked the Power KVM CI guys if they've faced this problem?
14:38:49 <esberglu> No
14:38:50 <edmondsw> do they do multinode in their CI?
14:38:59 <esberglu> I don't think so, I can check
14:39:03 <edmondsw> k
14:39:21 <esberglu> The big blocker for multinode is the jenkins dropping connections on the staging environment
14:40:00 <esberglu> Which I'm completely in the dark on, I spent a TON of time trying to figure this out when I was working the queens upgrade
14:40:05 <edmondsw> have you asked for help from infra?
14:40:22 <edmondsw> it sounds like a possible jenkins issue
14:40:37 <esberglu> Yeah I guess that's the next step
14:40:38 <edmondsw> I know they're not hitting it, but they have experience tracking down these problems, right?
14:41:06 <esberglu> edmondsw: Problem with that error message is that it could be a billion different things
14:41:12 <edmondsw> and it may very well be a jenkins bug they just haven't hit because of environment differences or something
14:41:19 <edmondsw> esbergly yep exactly
14:41:21 <esberglu> But I'll see if they can shed some light
14:41:59 <esberglu> But that is 100% blocking multinode CI right now and is my top priority
14:42:45 <esberglu> Nothing else from me
14:42:58 <edmondsw> #topic Open Discussion
14:43:06 <edmondsw> anything?
14:43:16 <esberglu> efried: You interested in being included in the PowerVM CI education sessions at all?
14:43:28 <efried> um
14:43:33 <edmondsw> lol
14:43:42 <efried> Does it increase the probability that I will be called upon to work on the CI?
14:43:49 <efried> cause then no
14:44:11 <esberglu> I'll leave you be :)
14:44:24 <edmondsw> I don't see that happening... but you might still want to be able to plead ignorance anyway :)
14:44:49 <edmondsw> better use of your time and all that
14:45:00 <edmondsw> alright, if nothing else...
14:45:05 <edmondsw> #endmeeting