14:00:48 #startmeeting PowerVM Driver Meeting 14:00:49 Meeting started Tue Sep 18 14:00:48 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:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:52 The meeting name has been set to 'powervm_driver_meeting' 14:00:55 #link agenda: https://etherpad.openstack.org/p/powervm_driver_meeting_agenda 14:01:54 efried mujahidali y'all here? 14:02:06 ^ 14:02:20 ō/ 14:02:23 #topic In-Tree Driver 14:02:44 I haven't had any time to look at this in a while, and probably won't for a while 14:02:56 efried anything we should discuss here, particularly anything from the PTG? 14:03:31 um 14:03:39 no, I don't think so. 14:03:42 cool 14:03:44 moving on 14:03:51 #topic Out-of-Tree Driver 14:04:11 I've got a WIP patch up to update our devstack examples: https://review.openstack.org/#/c/601628/ 14:04:43 still working on some things there, but the SEA changes work 14:04:51 it's an ongoing, as-able type of thing 14:06:11 mdrabe has also been working on secure boot: https://review.openstack.org/#/c/595877/ 14:06:37 there was a bug in pypowervm 1.1.17 so we had to release 1.1.18 for this to work properly 14:06:54 I believe the patch has been updated to use 1.1.18 now, but last I checked that wasn't in u-c yet so it wouldn't work 14:07:21 #action edmondsw check on u-c for pypowervm 14:07:39 anything else to discuss for OOT? 14:08:38 mdrabe how are things looking for you to test MSP support, time-wise? 14:09:04 I can spare a moment 14:09:12 Do we have a multinode env? 14:09:45 I have one devstack aio up that you could use, but not a 2nd compute to go with it 14:09:56 rather, I have a second system partly setup, but not devstacked 14:10:22 I am tied up in other things atm, but if you're available to work on that I could give you a devstack local.conf that I think should work and you could try it / play with that to get things working 14:11:10 I can lend my machine if you need a second. 14:11:17 Maybe, that'll take me some time. Got some other stuff to get to first 14:11:26 thanks, but it'll need to be the 2nd that I already identified, so they share an SSP 14:11:37 rather, I already set it up to use the same SSP 14:11:41 ight 14:12:05 mdrabe ok, let me know when you can get to it 14:12:13 #topic Device Passthrough 14:12:17 efried ^ 14:12:52 * efried totally unprepared to report on anything 14:13:13 Sean Mooney and I are going to work through some of the yaml file format ideas 14:13:36 Rahul is going to start working on a PoC based on what we've got at the moment. 14:14:00 Cyborg just might have a spawn-only solution in Stein. 14:14:33 well, a flavor vehicle, so technically I suppose you could hot attach with resize. 14:14:42 not sure if that's going to be a supported path. 14:15:01 closing on nrp is top priority 14:15:27 That's about all I've got for now, until I get my head organized again. Hopefully more coherent next week. 14:15:30 Any questions? 14:15:50 much discussion at the PTG about this stuff? 14:16:04 yes, from several angles. 14:16:08 Mainly cyborg 14:16:22 Let me summarize what that's going to look like for phase 1 14:16:38 cyborg API/CLI to create a "device profile" 14:16:47 Stuff a reference to that profile into the flavor 14:16:49 boot with the flavor 14:17:12 is that device profile anything like what we've designed to put in our yaml? 14:17:25 compute communicates with cyborg to turn that reference into an object to pass to virt. Virt does the attach. 14:17:48 It's analogous to a neutron port. 14:18:12 So you create it with e.g. a resource class and traits, and it's just hanging out there in the world. 14:18:29 Then you boot with it and there's a point where it gets "bound" - only then does it become part of an instance+host. 14:18:46 And then the bound thingy is what gets passed to the virt driver, which does the attach. 14:20:36 As for the yaml file, we agreed we were going to try to make it a common format that could be read by cyborg and/or nova. 14:20:44 I assume "boot with it" = "cyborg programming an FPGA" 14:20:48 no 14:21:04 phase 1 I believe we're just talking about non-programmable device passthrough. 14:21:16 I mean nova boot --flavor X 14:21:35 where flavor X contains a reference to the device profile thingy (VAR - Virtual Accelerator Reference - I believe) 14:22:05 then I have no idea what this means: "Then you boot with it and there's a point where it gets "bound" - only then does it become part of an instance+host." 14:22:45 if it's not programming, then the thing exists on the host before any of this process has started, nothing is creating it 14:24:02 openstack var create --resource-class GPU --traits CUSTOM_FOO CUSTOM_BAR 14:24:02 ==> $var_uuid 14:24:02 openstack flavor update --flavor X --extra-specs hw:cyborg:var:$var_uuid 14:24:02 nova boot --flavor X 14:24:31 or are you talking about inventorying and discovery? 14:25:41 actually maybe s/var_uuid/profile_name/ -- I don't think these are one-time-use gizmos, I think they're more like flavors themselves. So the "binding" step actually picks a specific device on the host. 14:25:48 now I can't remember 14:25:52 But Sundar is going to put up a spec. 14:25:59 I'll wait and read the spec 14:26:12 ping me when it's up? 14:26:17 https://etherpad.openstack.org/p/stein-ptg.cyborg-nova-new 14:27:04 lot there 14:27:23 is this being actively looked at, or are comments there a waste of time? 14:27:39 s'why I prefer commenting in reviews 14:27:58 plus they have more structure so easier to make sense of them 14:29:29 I don't know if Sundar is still consuming that to construct his spec. 14:29:46 In any case, yeah, I'll let you know when I see that spec come through. 14:29:50 tx 14:29:54 But in the meantime, if you have questions/comments, I may be able to answer them 14:29:59 because they may have already been discussed 14:30:09 we had several hours to get to this point. 14:30:22 I wasn't able to follow what you meant above, so... 14:30:52 above where? 14:30:56 a lot of it 14:31:31 looking at the etherpad helped me understand 'bound 14:31:48 guess it helps to be familiar with the neutron flow 14:31:49 I'll see if I can figure out the rest later if i get some time 14:31:52 which I *barely* am. 14:32:02 might, but I don't think that's my issue here 14:32:20 anyway, moving on 14:32:21 k, well, let me know if you want to discuss further. 14:32:23 yeah 14:32:29 #topic PowerVM CI 14:32:43 mujahidali how are things? 14:33:01 yesterday you had identified a couple nodes that were always timing out.. that fixed? 14:33:06 Jobs running on Neo24 and ne08 are taking too long to complete and eventually failing after timeout and neo 6 was having some problem with pvmctl so restarted neo6 and redeployed neo,6,8,24. 14:33:34 CI run looks better now. 14:33:40 great, tx 14:35:09 that it? 14:35:18 I have tried installing nodepool,zuul and jenkins on my test env but things are a little complicated 14:35:33 that sounds like an understatement :) 14:35:41 nodepool and zuul are not launching 14:35:49 did you also install zookeeper? 14:35:55 no 14:36:01 I remember esberglu saying that would be needed with the newer versions 14:36:07 okay 14:36:44 I first want to try it on dev env then stage and then prod. 14:37:04 you have a dev env other than the staging env? 14:37:06 if so, great 14:37:22 I am just using vms 14:37:44 to look how installation and config is working. 14:37:44 k 14:37:50 sure 14:38:33 we had a discussion for the blacklist and whitelist for the 700 test case with :efried 14:39:12 I am not able to conclude from that discussion. 14:39:28 I think we table that for the time being 14:39:36 okay 14:39:53 anything else? 14:39:56 that's it from me. 14:40:01 thanks 14:40:07 :) 14:40:08 #topic Open Discussion 14:41:02 nothing from me here 14:41:07 anyone else? 14:41:19 no 14:42:02 alright, thanks everyone 14:42:05 #endmeeting