14:08:37 <edmondsw> #startmeeting PowerVM Driver Meeting
14:08:37 <openstack> Meeting started Tue Oct 23 14:08:37 2018 UTC and is due to finish in 60 minutes.  The chair is edmondsw. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:08:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:08:41 <openstack> The meeting name has been set to 'powervm_driver_meeting'
14:09:10 <edmondsw> efried: mdrabe: mujahidali: getting started
14:09:20 <efried> o/
14:10:00 <edmondsw> #link agenda https://etherpad.openstack.org/p/powervm_driver_meeting_agenda
14:10:22 <edmondsw> #topic In-Tree Driver
14:11:23 <edmondsw> I've been working on a bug fix IT: https://review.openstack.org/#/c/610174/
14:12:09 <edmondsw> I think we're pretty close to merging that, and I will propose the same for OOT
14:12:42 <edmondsw> anything else to discuss IT?
14:13:21 <efried> not here
14:13:24 <edmondsw> #topic Out-of-Tree Driver
14:13:48 * efried saves for device passthrough topic
14:13:51 <efried> nothing else from me
14:14:32 <edmondsw> ceilometer-powervm tests were broken by a requirements change, but I think we have those working again now
14:15:21 <edmondsw> last I checked there was still a commit pending to re-enable testing with ceilometer master in the gate instead of with ceilometer stable/rocky
14:15:56 <edmondsw> oh, good... looks like that finally merged: https://review.openstack.org/#/c/609823/
14:15:59 <efried> in what repo?
14:16:00 <efried> yeah
14:16:31 <edmondsw> I think we're still going to need to backport that to rocky
14:16:50 <edmondsw> which will enable testing with stable/rocky changes that haven't been tagged in a new ceilometer release yet
14:17:02 <edmondsw> I'll propose that today
14:17:28 <efried> will need to be done manually.
14:17:42 <edmondsw> And then as mentioned above, I'll propose the bug fix I've been working on IT
14:18:01 <edmondsw> efried it certainly won't be a clean backport
14:18:24 <efried> If you're on a roll, you could also do that pypowervm py37 thing that's been back-burnered for a while. py37 is heating up.
14:18:45 <edmondsw> efried I don't know that I'm on that much of a roll :)
14:19:04 <edmondsw> I still have that on my todo list, but I have no idea when I'll be able to get to it
14:19:47 <efried> bug 1785255  (<== /me checks whether we've got that bot in here)
14:19:47 <openstack> bug 1785255 in pypowervm "py3.7 test failures" [Undecided,Confirmed] https://launchpad.net/bugs/1785255
14:19:49 <efried> yup
14:19:50 <edmondsw> as for py37, since you brought that up... I've been trying to follow all the ML posts and commenting on related commits as we determine which py3.x will be supported going forward, etc.
14:20:16 <edmondsw> that brings up a whole bunch of issues for us
14:20:24 <efried> whee
14:20:35 <edmondsw> a quick rundown from the top of my head:
14:20:57 <edmondsw> 1) Ubuntu 18.04 isn't supported on PowerVM, so the newest we can test with is py35
14:21:19 <efried> unless we install py37 on whatever ubuntu we do support??
14:21:43 <efried> it's not like py37 won't run on older ubuntus. It's just not what's shipped there.
14:21:57 <edmondsw> I don't know if that's possible. I've been tackling that more from the perspective of a) trying to get OpenStack to keep support for py35 and b) trying to get Ubuntu 18.04 supported on PowerVM at least for NovaLink
14:22:24 <edmondsw> but yeah, should probably try to figure out what can be done to run py37 on Ubuntu 16.04
14:22:47 <efried> I've got it running on my victim rn
14:23:02 <efried> that's where we were testing and debugging the pypowervm stuff, remember?
14:23:08 <edmondsw> 2) we're supposed to start testing py36 or py37 in both UT and CI
14:23:25 <edmondsw> efried true... did you pull it down from source or find a deb?
14:23:44 <efried> trying to figure that out now. I may have pulled a tarball. It's not in dpkg
14:24:24 <edmondsw> I'll try to figure out if whatever deb(s) for py36 in Ubuntu 18.04 will work in Ubuntu 16.04
14:25:33 <edmondsw> this transitions into CI discussion, so...
14:25:40 <edmondsw> #topic PowerVM CI
14:26:00 <edmondsw> We merged a CI change yesterday to get local2remote working in py3
14:26:16 <edmondsw> so that mujahidali can work on getting the CI to run as py3 instead of py2
14:26:32 <edmondsw> mujahidali did you get a chance to try that again with the local2remote change?
14:27:10 <edmondsw> (this would be py35 at this point, since it's an Ubuntu 16.04 image without additional py3.x releases added)
14:27:11 <mujahidali> I tried to redeploy the stage env(to pick :edmonds's changes) and I got the same error again.
14:27:20 <edmondsw> boo
14:27:31 <edmondsw> so slack me the env info again and I'll take a look
14:27:50 <mujahidali> sure
14:27:50 <edmondsw> what else do you have to report for the CI today?
14:27:52 <mujahidali> There is some problem with the os4p cloud due to whcih zuul-mergers nodes are down hence, there is no job in the queue. I will look into it once os4p is back.
14:28:27 <edmondsw> ah, yep, we're at the mercy of os4p now that we have the zuul mergers there
14:28:40 <mujahidali> yes.
14:28:58 <efried> edmondsw: Based on my browser history, I probably built 3.7 from source following https://serverfault.com/questions/918335/best-way-to-run-python-3-7-on-ubuntu-16-04-which-comes-with-python-3-5
14:29:02 <edmondsw> I wonder if we should run other things there as well, or move the merger nodes where everything else is... so we're only at the mercy of one infrastructure instead of 2
14:29:17 <edmondsw> efried ack thanks
14:29:57 <mujahidali> earlier all zuul-mergers were jupiter
14:30:10 <edmondsw> yeah, so it's not a new problem, just moved from jupiter to os4p
14:30:22 <edmondsw> not an immediate concern... just thinking out loud
14:30:44 <mujahidali> On multinode-front I installed zookeper and trying to figure out how it connects with nodepool(using this https://zuul-ci.org/docs/nodepool/configuration.html as ref I am able to connect zookeper with nodepool). Now I am getting error with diskimage-builder, there is some issue with nodepool py2 and py3.
14:31:30 <edmondsw> sounds like you're making progress, though. Good
14:32:44 <edmondsw> mujahidali anything else?
14:32:56 <mujahidali> that's it from me.
14:33:28 <edmondsw> #topic Device Passthrough
14:33:32 <edmondsw> efried ^
14:33:39 <efried> There is general support for the idea of a generic provider config file, and a consensus that the design for that should be split out from the device passthrough spec(s). So I did that:
14:33:39 <efried> #link Provider config YAML spec https://review.openstack.org/#/c/612497/
14:34:07 <efried> It accomodates the device passthrough use case, plus a bunch of others.
14:34:20 <efried> Today is a spec review sprint for nova. Hoping this gets some attention.
14:34:41 <efried> The idea is hopefully to get it close enough to baked that we can go and implement it at least OOT
14:34:56 <efried> it'll be a delta from what we've got proposed right now (and from what's in the merged spec)
14:35:00 <edmondsw> anything I should be concerned about in there?
14:35:08 <efried> what do you mean, concerned about?
14:35:14 <efried> You should read it
14:35:27 <efried> but no, there shouldn't be anything hugely worrisome.
14:35:29 <edmondsw> yep, I loaded the link and will try to read
14:35:33 <edmondsw> k good
14:35:43 <efried> The subset that deals with device stuff is pretty much the same as what we had before.
14:35:58 <efried> um
14:36:26 <efried> yeah, even including how to identify via traits and how to add/remove traits.
14:37:02 <efried> but this spec leaves out the (controversial) part about us autogenerating a bunch of traits based on things like PCI vendor ID and whatnot.
14:37:29 <efried> That's the "split" aspect.
14:37:57 <efried> That's all I have for the moment on passthrough.
14:38:06 <edmondsw> ok, thanks
14:38:14 <edmondsw> #topic Open Discussion
14:38:21 <edmondsw> the floor is open...
14:38:57 * efried dances
14:39:05 * efried sits
14:39:09 <efried> nothing here
14:39:17 * edmondsw enjoyed that
14:39:23 <edmondsw> #endmeeting