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