Earlier  
Posted Nick Remark
#openstack-cyborg - 2018-06-04
14:02:54 shaohe_feng #startmeeting openstack-cyborg-driver
14:02:55 openstack Meeting started Mon Jun 4 14:02:54 2018 UTC and is due to finish in 60 minutes. The chair is shaohe_feng. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:56 openstack Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:58 openstack The meeting name has been set to 'openstack_cyborg_driver'
14:03:14 shaohe_feng #topic Roll Call
14:03:28 Sundar_ #info Sundar
14:03:29 shaohe_feng #info shaohe
14:04:16 Helloway #info Helloway
14:05:53 shaohe_feng Sundar_, let's wait minutes for other?
14:06:21 shaohe_feng evening wangzhh
14:06:23 tony hi
14:06:35 shaohe_feng hello tony
14:06:58 wangzhh hello everyone
14:07:11 tony hello everyone
14:07:32 Sundar_ shaohe: Sure
14:08:12 shaohe_feng OK. let's start.
14:08:19 Sundar_ Hi Tony
14:08:26 Sundar_ Hi Wangzhh
14:08:29 Guest4480 Hi
14:08:31 shaohe_feng welcome tony
14:08:39 shaohe_feng #topic current status of drivers
14:09:16 tony ths shaohe
14:09:17 shaohe_feng I have list the tasks on the etherpad #link https://etherpad.openstack.org/p/cyborg-driver-tasks
14:09:53 shaohe_feng let go through the tasks
14:10:20 shaohe_feng wangzhh, are you going on the VGPU?
14:10:31 wangzhh OK. Let introduce my work.
14:10:50 shaohe_feng welcome.
14:11:08 wangzhh I'm going on the VGPU.
14:11:42 wangzhh And when I merged my code. I find some exist bug:(
14:12:12 wangzhh cyborg-agent doesn't work well.
14:12:35 wangzhh Such as https://review.openstack.org/#/c/572080/
14:13:56 wangzhh So, before VGPU driver, maybe I should fix them first.
14:14:13 shaohe_feng good catch.
14:14:49 shaohe_feng so this is an urgent fix.
14:15:10 xinran__ Hi sorry for being late
14:15:21 shaohe_feng xinran__, evening.
14:15:50 shaohe_feng Li_liu is not on line.
14:16:11 shaohe_feng he introduce deployable object.
14:17:04 shaohe_feng Sundar_, and other developers, please help to review wangzhh bug fix
14:17:15 shaohe_feng #link https://review.openstack.org/#/c/572080/
14:18:05 shaohe_feng wangzhh, other process on VGPU? can you help to update the task list? #link https://etherpad.openstack.org/p/cyborg-driver-tasks
14:19:12 shaohe_feng ^ wangzhh, update the status.
14:19:23 shaohe_feng OK, next.
14:19:29 wangzhh shaohe_feng: OK
14:19:46 shaohe_feng SPDK, Helloway are you on line?
14:20:38 Helloway yes
14:21:15 shaohe_feng so any process on the SPDK?
14:22:37 Helloway Temporarily no
14:24:38 shaohe_feng Helloway, can you help to update the SPDK status on the #link https://etherpad.openstack.org/p/cyborg-driver-tasks
14:24:58 shaohe_feng OK, next provider report.
14:25:52 shaohe_feng Sundar_, Do we support multi-resource class and nest provider in this release
14:26:09 Sundar_ Shaohe: IMHO, it is becoming risky
14:26:31 shaohe_feng Sundar_, what's the risky?
14:26:38 Sundar_ We have been waiting too long. Even in today's discussion in Nova scheduler meeting, it is not clear that it is going to come soon
14:27:05 shaohe_feng how should we do?
14:27:08 Sundar_ IMO, we should switch immediately to my originally proposed plan to use compute node as RP, till we get nRP
14:27:56 Sundar_ This means we can have multiple devices on the same host but they must all have the same types/traits
14:28:02 shaohe_feng OK. Can you have a discuss with jaypipes about cyborg's resource provider?
14:28:11 shaohe_feng during the summit?
14:28:30 Sundar_ E.g. 2 GPUs, 2 FPGAs both from Xilinx with same device family, 2 FPGAs both from Intel (say A10) etc
14:29:22 Sundar_ I discussed with edleafe etc., primarily on the comments that we should not have vendor/product/device names in traits.
14:29:40 Sundar_ That got resolved, because we do need vendor/device names, but not product names. The spec has been updated
14:29:57 Sundar_ On nRP, it is a larger discussion, that is still going on in the Nova community
14:30:09 shaohe_feng if we have a 1 Xilinx and 1 intel's FPGA on one host, what's the resource name? and what's the traits name?
14:30:33 Sundar_ We cannot have that unless we get nRPs. I'll explain why
14:30:47 shaohe_feng OK. please
14:31:04 Sundar_ For each device (GPU or FPGA), we will apply a trait like CUSTOM_GPU_AMD, CUSTOM_FPGA_INTEL
14:31:30 Sundar_ In your example, it will be CUSTOM_FPGA_INTEL and CUSTOM_FPGA_XILINX
14:31:55 Sundar_ We will also publish the resource class as CUSTOM_ACCELERATOR_FPGA
14:32:14 edleafe I would prefer 2 nested children, each with an inventory of 1 CUSTOM_FPGA. Then use traits to distinguish them
14:32:20 Sundar_ However, without nRP, it will get applied on the compute node, not on the individual devices
14:32:47 Sundar_ shaohe: that requires nRP. We may not get that soon enough to meet our Rocky goals.
14:33:26 edleafe There is currently discussion in placement on the potential upgrade problems when moving from non-nested to nested. It would be better to only plan on implementing on the nested model if possible
14:34:00 Sundar_ Without nRP, it will get applied on the compute node. So, the cpmpute node will advertise 2 units of CUSTOM_ACCELERATOR_FPGA, with 2 traits: CUSTOM_FPGA_INTEL and CUSTOM_FPGA_XILINX. But, Placement wil see that as 2 RCs each with 2 traits
14:34:23 Sundar_ There is no way to say that one unit of the RC has one trait, and the other has another trait
14:34:59 Sundar_ Does that make sense?
14:35:07 edleafe Sundar_: precisely. That's the main reason for waiting for nested
14:35:58 shaohe_feng edleafe, Sundar_ : there's issue in this way.
14:36:24 Sundar_ edleafe: Thanks for joining. My concern is, we are already in June and even today's Nova sched discussion indicates concerns with rolling upgrades and nRPs
14:36:46 Sundar_ It would be better to get something done with caveats, than nothing
14:37:23 shaohe_feng for example, user apply one CUSTOM_FPGA_XILINX, then inventory will remain one intel's CUSTOM_ACCELERATOR_FPGA
14:37:49 shaohe_feng then user still apply one CUSTOM_FPGA_XILINX, what's will go on?
14:38:04 edleafe But besides the issues noted with moving from non-nested to nested, Cyborg will also have to re-do a lot of the naming of custom resource classes
14:38:11 Sundar_ shaohe: traits go with resource providers (RPs), not resource classes (RCs)
14:39:55 shaohe_feng Sundar_, yes, that's issue.
14:40:41 shaohe_feng Sundar_, so the user still can apply a FPGA, but not XILINX that he expect.
14:44:16 shaohe_feng edleafe, any suggestion on this issue?
14:44:48 Sundar_ Hi
14:45:02 openstackgerrit wangzhh proposed openstack/cyborg master: Fix Deployable get_by_host https://review.openstack.org/572080
14:45:16 Sundar_ Can you see my typing?
14:45:20 shaohe_feng Sundar_, welcome to come back
14:45:33 shaohe_feng Sundar_, just see "Hi"
14:45:37 Sundar_ I got blocked for some reason -- whatever I typed did not show up
14:45:49 shaohe_feng edleafe, Sundar_ , only support one kind of FPGA to avoid this issue?
14:46:13 Sundar_ Yes, omultiple devices ok, but all of the same type
14:46:30 Sundar_ We cannot have a GPU and a FPGA on the same host, or 2 kinds of FPGAs
14:46:39 Sundar_ That should be ok for Rocky
14:48:05 edleafe shaohe_feng: sorry, had to step away for a moment
14:48:39 edleafe shaohe_feng: FPGA is a resource *class*. GPU is a resource *class*
14:48:49 edleafe They should be modeled that way from the start.

Earlier   Later