14:00:08 <edmondsw> #startmeeting PowerVM Driver Meeting
14:00:09 <openstack> Meeting started Tue Mar 20 14:00:08 2018 UTC and is due to finish in 60 minutes.  The chair is edmondsw. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:12 <openstack> The meeting name has been set to 'powervm_driver_meeting'
14:00:28 <esberglu> \o
14:00:40 <efried> @/
14:00:46 <edmondsw> agenda: https://etherpad.openstack.org/p/powervm_driver_meeting_agenda
14:00:57 <edmondsw> #topic In-Tree Driver
14:01:06 <edmondsw> https://etherpad.openstack.org/p/powervm-in-tree-todos
14:01:24 <edmondsw> esberglu I just gave you a few easy comments on the vscsi commit
14:01:37 <edmondsw> then that should be good for efried to look at
14:02:06 <efried> I'm still ploughing my way through my review backlog, and the in-tree patches are on it.
14:02:06 <edmondsw> we're stacking things up for the nova cores to look at, with none of them actually looking for a while
14:02:13 <edmondsw> +1
14:02:15 <esberglu> edmondsw: Saw that. Yep once I fix those it's ready for review
14:02:32 <efried> We ought to have runways kicked off "soon" - like maybe this week
14:02:33 <edmondsw> efried I would look at that one next of the IT patches
14:02:33 <esberglu> I live tested attach/detach again which looks good and also got extend_volume working
14:02:43 <edmondsw> next on my list is snapshot, then disk adapter
14:02:50 <esberglu> edmondsw: Cool
14:03:04 <edmondsw> esberglu anything else you want to say for IT?
14:03:11 <efried> in which case we can queue up the couple we have ready
14:03:28 <esberglu> I just had a question about microversions
14:03:28 <edmondsw> efried sorry I didn't follow that
14:03:39 <edmondsw> ask away
14:04:23 <esberglu> When I was issuing commands using the cinder CLI it was defaulting to 3.0
14:04:48 <esberglu> In cinder/api/openstack/api_version_request.py
14:05:02 <esberglu> I changed the  _MIN_API_VERSION = "3.42"
14:05:14 <esberglu> The level required for extending attached volumes
14:05:29 <esberglu> Is that the proper way to go about changing the min?
14:05:31 <edmondsw> no
14:05:49 <efried> For the CLI?  Yes.  It isn't?
14:05:50 <esberglu> I couldn't find a clear answer in my googling
14:05:59 <edmondsw> wait... maybe I'm not following what you're trying to do
14:06:15 <edmondsw> are you working on a cinder change?
14:06:26 <efried> edmondsw: I got this.
14:06:35 <esberglu> edmondsw: No I was testing extend_volume in the vSCSI change
14:06:39 <efried> esberglu: Different CLIs are different.
14:06:49 <edmondsw> then you just need to set an env var, not alter code
14:07:11 * edmondsw letting efried explain
14:07:16 <efried> Some default to minimum version.  Some default to a specific version.  Some negotiate latest version with the server per call.  Clearly cinder is the first one.
14:07:34 <efried> And yes, there's an env var and/or flag you can specify to the CLI to get a different version.
14:07:49 <efried> AND the CLI has to know how to handle whatever operation you're trying to execute.
14:08:00 <edmondsw> yep
14:08:09 <efried> So sometimes it may not be sufficient just to increase the version.
14:08:27 <edmondsw> I think in this case I checked and it should be, but that was last week so... :)
14:08:27 <efried> But it sounds like in this case you determined that the CLI *does* support it, and that you need to use 3.42 to get that support switched on.
14:08:30 <efried> So you're doing the right thing.
14:09:04 <edmondsw> efried by altering code? why would you say that over using an env var?
14:09:14 <efried> eh?  I never said altering code.
14:09:33 <edmondsw> esberglu said he changed _MIN_API_VERSION in cinder/api/openstack/api_version_request.py
14:09:35 <efried> Oh, I didn't follow that esberglu was actually changing code.  My bad.
14:09:47 <edmondsw> or at least that's how I read it
14:09:47 <esberglu> Yeah I should have used an env. var but the end result is the same
14:09:50 <efried> esberglu: There'll be an env var and/or CLI option to set the microversion.
14:09:54 <efried> Do that instead.
14:10:04 <efried> But if you're just testing locally, meh.
14:10:07 <edmondsw> sure
14:10:15 <efried> edmondsw: Runways.  In Nova.  Basically a mechanism to promote more equitable distribution of review time.  See https://etherpad.openstack.org/p/nova-runways-rocky
14:10:40 <esberglu> Anyways, point is that extend_volume works for attached vSCSI volumes if using the right microversion
14:10:49 <edmondsw> cool
14:11:32 <esberglu> That's all I had
14:11:40 <esberglu> Just need reviews on snapshot and vscsi
14:12:05 <edmondsw> efried we need to get the spec approved...
14:12:26 <esberglu> efried: Saw that you asked about fast approve there, hopefully someone will push it through
14:12:53 <edmondsw> I pinged melwitt the other day and she said just to put it on https://etherpad.openstack.org/p/rocky-nova-priorities-tracking which it was, but no activity yet
14:13:36 <efried> Yeah.  Re spec approval, when we talked about it the other day, I mentioned that we shouldn't be too strict about the "whole approved blueprint" aspect of this.
14:13:58 <efried> So like, I fully intend to put the spec down as part of the runway if it's not approved by the time we get this going.
14:14:10 <efried> esberglu: btw, are you planning to go on vacation any time soon?
14:14:20 <efried> or be otherwise unavailable to address review comments quickly?
14:14:36 <esberglu> efried: Nothing more than a day or 2 until July
14:14:45 <efried> cause that would be the main thing stopping us from queuing up a runway.
14:15:32 <edmondsw> we won't want to wait for "The code for the blueprint must be 100% ready for review"
14:16:54 <edmondsw> I read the "If a blueprint is too large" following sentence as saying it still has to be 100% ready, but it doesn't have to all be reviewed in the same runway... but I hope I'm wrong there
14:17:32 <efried> jgwentworth was supposed to leave the discussion in a separate etherpad.
14:17:42 <efried> oh.
14:17:44 <efried> It's at the bottom.
14:18:01 <edmondsw> cool, I'll read over that later
14:18:08 <edmondsw> and add comments as appropriate
14:18:10 <edmondsw> tx for the link
14:18:22 <edmondsw> anything else for IT?
14:18:28 <esberglu> nope
14:18:52 <edmondsw> #topic Out-of-Tree Driver
14:18:59 <edmondsw> https://etherpad.openstack.org/p/powervm-oot-todos
14:19:23 <edmondsw> I did some more reviewing on the refactor... need to finish that and post the comments
14:19:50 <efried> I did some reviewing there.  Did I post comments?
14:19:55 <efried> I can't remember whether I saved 'em.
14:20:04 <efried> yeah
14:20:11 <edmondsw> yep, I see 'em
14:20:20 <efried> I'm still -0.5 until we get some live testing.  Which is gonna suck.
14:20:45 <edmondsw> yeah, I think we're all agreed this will need some good testing
14:21:01 <edmondsw> just wanted to get comments addressed first, so we're not doing that multiple times
14:21:18 <efried> yuh
14:21:28 <edmondsw> and I uncovered something interesting while digging through this... we don't have iSCSI live migration implemented
14:21:49 <edmondsw> so I added that to the TODO list. PowerVC wants it
14:22:52 <edmondsw> the other big thing OOT is https://review.openstack.org/552172
14:23:15 <edmondsw> hope to see a pypowervm release today or tomorrow so we can propose a requirements bump and unblock that
14:23:27 <edmondsw> anything else to discuss OOT?
14:23:52 <efried> actually
14:23:59 <efried> have we released pypowervm yet?  Or tagged it or whatever?
14:24:04 <edmondsw> no
14:24:05 <esberglu> Nope
14:24:17 <efried> Cause I had one comment in the refactor about something that we should be doing in pypowervm instead of nova-powervm.
14:24:21 <edmondsw> I asked about that yesterday, and you and hsien both said sure, but it hasn't been done
14:24:28 <efried> So if we could get that into the release, that would help.
14:24:38 <edmondsw> absolutely
14:24:47 <edmondsw> let's drive that today
14:25:17 <esberglu> efried: edmondsw: IIRC that was a vscsi comment that will apply IT as well
14:25:25 <edmondsw> https://review.openstack.org/#/c/530816/6/nova_powervm/virt/powervm/volume/fcpvvscsi.py@48
14:25:45 <edmondsw> ah, yeah, that would apply to the IT commit as well
14:26:03 <efried> cool
14:26:18 <edmondsw> anything else?
14:26:25 <efried> Well, first we need someone to confirm that always caching it is The Right Thing.
14:26:57 <efried> I don't know from WWPNs, so that someone ain't me.
14:27:16 <edmondsw> certainly... you want to discuss that here or after the mtg?
14:27:33 <edmondsw> I'd rather do after so I can stop and think about it
14:27:52 <efried> ight
14:27:58 <edmondsw> #topic Device Passthrough
14:28:12 <edmondsw> efried and I went through use cases yesterday and took some notes
14:28:51 <edmondsw> I need to work that up and get a mtg on the calendar with the NovaLink guys
14:29:05 <edmondsw> efried you have the floor
14:29:41 <efried> Nothing to add
14:29:48 <edmondsw> k
14:29:58 <edmondsw> #topic PowerVM CI
14:30:05 <edmondsw> https://etherpad.openstack.org/p/powervm_ci_todos
14:30:10 <edmondsw> esberglu ?
14:30:49 <esberglu> Since the start of the weekend CI has not been looking great, a bunch of new failures and long runs
14:31:06 <esberglu> I've been taking inventory of failures here https://etherpad.openstack.org/p/powervm_tempest_failures
14:31:18 <esberglu> That's what I'll be working on today
14:32:03 <edmondsw> esberglu sure... focus on that and hold off on the vscsi IT commit respin while we workout the question of whether to move that into pypowervm
14:32:38 <esberglu> edmondsw: Yep I'm gonna just sit IT until we start getting some movement so I don't have to rebase the world
14:32:46 <esberglu> Other than that the CI management upgrade is ongoing, facing some roadblocks upgrading nodepool
14:32:52 <esberglu> We're currently nodepool 0.3.0
14:33:24 <esberglu> Starting in 0.4.0 they don't allow the flow of taking an image, doing some stuff, taking a snapshot of it and spawning from the snapshot
14:33:36 <esberglu> And instead you have to use diskimage-builder
14:33:48 <esberglu> Which from what I've read so far only supports 14.04
14:33:58 <esberglu> And I really don't want to go back to 14.04 from 16.04
14:34:28 <edmondsw> I hope that's not right... someone you can catch on IRC to talk about that?
14:34:29 <esberglu> But there may be a way around that, I need to do some more recon
14:34:46 <edmondsw> not sure who... maybe tonyb?
14:35:18 <esberglu> edmondsw: I really haven't looked to much into, just saw a blurb about it. I'm sure there are people using new nodepool with 16.04
14:35:26 <esberglu> So there's got to be a solution
14:35:34 <edmondsw> good
14:36:02 <esberglu> The other thing I need to do is update the CI firmware
14:36:21 <edmondsw> getting the CI stable again is obviously the priority, but you might want to shoot off a couple feelers so that you have suggestions ready to try when you can get back to this
14:36:48 <esberglu> So I will need to find a good time to take the CI down for a day or so
14:37:20 <edmondsw> that related to the undercloud moving to queens, or just normal need to apply security updates and such?
14:37:25 <esberglu> Security updates
14:37:33 <edmondsw> ok good
14:37:49 <edmondsw> maybe do that on a Friday?
14:38:07 <esberglu> edmondsw: Yeah that was my plan, probably not until next week though
14:38:23 <esberglu> That's it for me
14:38:36 <edmondsw> #topic Open Discussion
14:38:36 <esberglu> I'll try to time it so we don't have much in the pipeline getting blocked
14:38:43 <edmondsw> +1
14:38:54 <edmondsw> I had one thing to bring up here
14:39:07 <edmondsw> we talked a little about the logo the other day: http://eavesdrop.openstack.org/irclogs/%23openstack-powervm/%23openstack-powervm.2018-03-14.log.html#t2018-03-14T19:03:19
14:39:17 <edmondsw> but I don't think I saw esberglu chime in
14:39:25 <edmondsw> any thoughts?
14:39:37 <edmondsw> or if anyone else is lurking and wants to throw something out there...
14:39:42 <esberglu> edmondsw: +1 on gorilla, thought that was a great idea
14:39:48 <edmondsw> cool
14:40:12 <edmondsw> then barring something unexpected, I'll ask for gorilla
14:40:29 <edmondsw> that's it from me
14:40:36 <esberglu> nothing else from me
14:40:44 <efried> wwpns?
14:40:58 <edmondsw> sure we can talk about that... let me go back to your comment
14:41:03 <efried> def get_physical_wwpns(adapter):
14:41:03 <efried> """Returns the active WWPNs of the FC ports across all VIOSes on system.
14:41:03 <efried> :param adapter: pypowervm.adapter.Adapter for REST API communication.
14:41:03 <efried> """
14:41:03 <efried> vios_feed = vios.VIOS.get(adapter, xag=[c.XAG.VIO_STOR])
14:41:03 <efried> wwpn_list = []
14:41:03 <efried> for vwrap in vios_feed:
14:41:05 <efried> wwpn_list.extend(vwrap.get_active_pfc_wwpns())
14:41:05 <efried> return wwpn_list
14:41:11 <efried> def get_active_pfc_wwpns(self):
14:41:11 <efried> """Returns a set of Physical FC Adapter WWPNs of 'active' ports."""
14:41:11 <efried> # The logic to check for active ports is poor.  Right now it only
14:41:11 <efried> # checks if the port has NPIV connections available.  If there is a
14:41:11 <efried> # FC, non-NPIV card...then this logic fails.
14:41:12 <efried> #
14:41:12 <efried> # This will suffice until the backing API adds more granular logic.
14:41:12 <efried> return [pfc.wwpn for pfc in self.pfc_ports if pfc.npiv_total_ports > 0]
14:42:10 <efried> So the question is: does the list of pfc_ports, or their number of npiv_total_ports, never* change?   (*without, like rebooting)
14:42:39 * efried has GOT to figure out how to turn off emojis in this IRC client)
14:42:44 <edmondsw> physical WWPNs shouldn't change unless you hotplug an adapter... but I think you can do that?
14:43:21 <efried> no idea
14:43:31 <edmondsw> so this may have been an oversight when the code was first written and we've just never hit an issue because folks don't hotplug FC adapters on a regular basis
14:43:32 <efried> If you can, then the nova-powervm code is wrong.
14:43:39 <efried> yeah, that.
14:43:43 <edmondsw> we should have this conversation with seroyer
14:43:48 <efried> ight.
14:44:10 <edmondsw> let's move that to slack so we can pull him in
14:44:14 <edmondsw> anything else before we close here?
14:44:42 <efried> nothing from me.
14:44:50 <edmondsw> #endmeeting