14:01:03 <edmondsw> #startmeeting PowerVM Driver Meeting
14:01:03 <openstack> Meeting started Tue Oct 30 14:01:03 2018 UTC and is due to finish in 60 minutes.  The chair is edmondsw. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:07 <openstack> The meeting name has been set to 'powervm_driver_meeting'
14:01:10 <efried> o/
14:01:14 <edmondsw> #link agenda: https://etherpad.openstack.org/p/powervm_driver_meeting_agenda
14:01:23 <edmondsw> #topic In-Tree Driver
14:01:52 <edmondsw> I'm waiting for a 2nd +2/+A on https://review.openstack.org/#/c/610174/
14:02:15 <edmondsw> I think that's the only thing we've currently got going in-tree
14:02:18 <efried> https://review.openstack.org/#/c/468560/
14:02:34 <efried> It was +A but then got bumped for the uuidsentinel change.
14:02:45 <efried> I might try to convince Jay to fast-approve it since the rebase was trivial.
14:03:00 <efried> But this patch deserves a bit of a closer look since...
14:03:12 <efried> https://review.openstack.org/#/c/613126/
14:03:29 <efried> ...where it is now officially the responsibility of the virt driver to set allocation ratios and reserved values.
14:03:59 <efried> Because https://review.openstack.org/#/c/613991/ is ripping out the bits where the resource tracker sets those outside of the virt driver, for the update_provider_tree path.
14:04:18 <edmondsw> i.e. we have to merge 468560 before those others can merge?
14:04:44 <efried> nope. Turns out I "predicted" the future here, and the powervm patch is already copacetic.
14:05:10 <efried> Once that second one merges, we'll get to do an optional optimization to call the base ComputeDriver method to calculate the disk reserve
14:05:39 <efried> this: https://review.openstack.org/#/c/613126/4/nova/virt/driver.py@860
14:06:06 <efried> right now that's inlined: https://review.openstack.org/#/c/468560/4/nova/virt/powervm/driver.py@203
14:06:34 <efried> In other in-tree news, don't forget to vote for the T release name.
14:06:39 <edmondsw> not sure I'm following, but I'll take a look after the meeting and it'll probably all come together
14:06:57 <edmondsw> I don't think I got an email about the T name vote yet...
14:07:09 <efried> http://lists.openstack.org/pipermail/openstack-dev/2018-October/136127.html
14:07:24 <efried> it's a public poll. So you can vote once per IP address. (but obviously just vote once)
14:07:39 <edmondsw> ah, that explains it
14:07:46 <efried> Are you on the Train train?
14:08:01 <edmondsw> yeah... though I also liked Thomas (the tank engine)
14:08:12 <edmondsw> and would have been cool to have suggested the name that got picked
14:08:22 <efried> Oh, was that your suggestion?
14:08:25 <edmondsw> yeah
14:08:29 <edmondsw> but I'll vote for Train
14:08:35 <efried> Thomas is on there
14:08:59 <efried> and it's ordered, and you can have ties
14:09:16 <edmondsw> yep
14:10:09 <edmondsw> #topic Out-of-Tree Driver
14:10:45 <edmondsw> similar to IT, we have https://review.openstack.org/#/c/613342/ needing a 2nd +2/+A
14:10:47 <edmondsw> mdrabe ^
14:11:55 <edmondsw> mdrabe I assume that's an easy test with PowerVC (for the bug you requested earlier) and then you can +2
14:12:14 <edmondsw> (looking at the code as well, of course)
14:12:25 <mdrabe> thnx will look
14:12:33 <mdrabe> edmondsw: Did we wanna backport that?
14:12:34 <edmondsw> tx
14:12:54 <edmondsw> I don't think I'll push backporting... I view it more as hardening than as a vulnerability
14:13:05 <efried> (Update: Success convincing Jay to fast-approve https://review.openstack.org/#/c/468560/)
14:13:10 <mdrabe> Sounds good
14:13:55 <edmondsw> #topic Device Passthrough
14:13:59 <efried> Oh, there was one more OOT thing...
14:14:09 <edmondsw> #topic OOT part 2
14:14:26 <efried> (edmondsw: there's also #undo)
14:14:35 <edmondsw> ah, nice
14:14:47 <efried> Got an email to our pypowervm github account, assume y'all got it too.
14:15:00 <efried> About requests <=2.19 having a security vulnerability.
14:15:16 <edmondsw> yeah, I got that
14:15:26 <efried> I checked the nova project, since we usually try to align with that.
14:15:27 <edmondsw> we should not be affected because pypowervm is only used with localhost
14:15:49 <edmondsw> removing the MITM concern
14:15:50 <efried> And it's at 2.14.2
14:16:04 <efried> okay, I didn't look into the vulnerability itself.
14:16:08 <efried> Just whether it was feasible for us to bump.
14:16:15 <efried> We're behind openstack anyway there.
14:16:23 <edmondsw> glad you brought it up
14:16:44 <efried> requirements project has upper constraint at 2.20
14:16:47 <efried> .0
14:17:05 <edmondsw> I don't know that we need to keep up with other OpenStack projects... kind of the point of having l-c in each project now instead of global like it used to be
14:17:30 <edmondsw> u-c will always be the latest available that we haven't found an issue with
14:17:38 <edmondsw> but l-c should be the oldest available that we don't have an issue with
14:17:40 <efried> yeah, sure
14:17:53 <efried> well, we don't have l-c in pypowervm
14:18:11 <efried> and we at least need to make sure we don't have conflicts.
14:18:39 <edmondsw> l-c for pypowervm is essential the lower bound listed in requirements.txt
14:18:40 <efried> but in this case it would let us clean up that req a bit. Right now it's a three-parter.
14:19:08 <edmondsw> efried so what exactly are you suggesting?
14:19:11 <efried> What I don't see is any patches bumping l-c in nova at large. Wonder if it just hasn't percolated down there yet.
14:19:18 <efried> sorry, s/nova/openstack/
14:19:41 <edmondsw> efried I'm guessing that it's still percolating
14:19:45 <efried> I'm not really suggesting anything yet. I kinda want to find out if anyone in openstack is concerned.
14:20:10 <efried> if so, we should bump our req to 2.20.0 just to align.
14:20:37 <efried> if not... I guess if you think the vulnerability is n/a for us, we could leave it.
14:20:37 <edmondsw> there I disagree... we don't need to align, any more than openstack projects need to align with each other
14:20:49 <edmondsw> this is why they moved l-c into individual projects, so that they don't have to align
14:21:02 <efried> Sorry, I didn't mean align for the sake of alignment.
14:21:13 <edmondsw> you meant specifically for this bug?
14:21:33 <efried> But if there's a known vulnerability and it's concerning enough that openstack bumps minimum to 2.20.0, then it's probably a good idea if we do too, even if it's not strictly necessary (at the moment).
14:21:42 <efried> But don't we have people consuming pypowervm in a remote fashion?
14:22:08 <edmondsw> I didn't think it supported that, without hacking
14:22:16 <edmondsw> maybe I need to take a closer look at what local2remote does
14:22:32 <edmondsw> I thought vanilla pypowervm could only be used locally
14:23:03 <efried> possibly
14:23:05 <efried> even so
14:23:17 <efried> from the other side, any harm in bumping the minimum?
14:24:01 <edmondsw> ok, the more I think of it, and just confirmed... local2remote isn't changing pypowervm code to make remote possible
14:24:15 <edmondsw> pypowervm does support remote
14:24:32 <edmondsw> so... yeah... we might want to bump
14:24:59 <edmondsw> we could leave it the way it is, and say that you're welcome to update requests but we just won't make you do it
14:25:12 <edmondsw> but probably better to bump
14:26:39 <edmondsw> let me make sure there is a python-requests 2.20.0 on both RHEL and Ubuntu 16.04 and 18.04 first
14:27:42 <edmondsw> #topic Device Passthrough
14:27:58 <edmondsw> efried ^
14:28:53 <efried> okay, the new file format spec got a couple reviews since last week. I was kinda waiting for more, but at this point I guess I'll incorporate those changes and push another rev soon.
14:29:23 <efried> https://review.openstack.org/#/c/612497/
14:29:43 <efried> otherwise, no progress.
14:30:05 <efried> also will need to respin the actual dev passthrough spec to account for having factored out --^
14:30:11 <efried> but haven't started that yet either.
14:30:29 <efried> EOM unless questions
14:30:45 <edmondsw> no questions. Haven't gotten to the spec yet
14:31:12 <edmondsw> #topic PowerVM CI
14:31:18 <edmondsw> mujahidali ^
14:32:27 <mujahidali> After redeploying the neos CI looks quite good that earlier but there is some problem in accesing the http://ci-watch.tintri.com/
14:32:42 <mujahidali> *than
14:34:59 <edmondsw> as long as the CI is working :)
14:35:09 <edmondsw> any update on other things?
14:35:10 <mujahidali> We are able to stack IT for py-3devstack(tempest was failing)
14:35:47 <edmondsw> you figured out the issues? I haven't seen any commit proposals for fixes
14:36:02 <mujahidali> the issue was in OOT
14:36:17 <edmondsw> I thought you were also looking at a pypowervm issue
14:36:39 <mujahidali> and I didn't get chance to test pypowervm changes.
14:37:21 <edmondsw> mujahidali are you going to propose a commit for an OOT fix?
14:37:29 <mujahidali> yes
14:37:39 <mujahidali> I need to test it first.
14:37:39 <edmondsw> +1
14:38:33 <mujahidali> and I will be pulled for some time as a backup for Bharath until he is back(for PVC-build).
14:39:37 <edmondsw> yep, understood
14:39:39 <edmondsw> anything else?
14:39:46 <mujahidali> that's it.
14:40:29 <edmondsw> #topic Open Discussion
14:41:15 <edmondsw> I'm only seeing python-requests 2.9.1 on Ubuntu 16.04.... :(
14:41:28 <efried> that wouldn't even satisfy our minimum, would it?
14:41:42 <efried> no
14:41:44 <edmondsw> true
14:42:28 <edmondsw> I'll keep looking into that
14:43:08 <mujahidali> any idea why it's http://ci-watch.tintri.com/ not working ?
14:43:46 <edmondsw> mujahidali no clue
14:43:52 <mujahidali> okay
14:44:01 <edmondsw> efried looks like Ubuntu didn't bump 2.9.1 to 2.20.0... they just patched 2.9.1 with the fix for this issue
14:44:08 <edmondsw> https://usn.ubuntu.com/3790-1/
14:44:30 <edmondsw> come to think of it, that kind of thing is common, and explains why you're not seeing other projects bumping versions
14:44:37 <efried> mm, interesting.
14:45:14 <efried> I'll see if anyone in -infra knows about ci-watch
14:45:27 <mujahidali> thanks
14:47:04 <edmondsw> alright, thanks everyone
14:47:06 <edmondsw> #endmeeting