| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-06-04 | |||
| 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. | |
| 14:49:01 | edleafe | specific types should be distinguished with traits | |
| 14:49:27 | Sundar_ | edleafe: That is exactly what we are doing | |
| 14:49:54 | edleafe | Sundar_: good. I really would hate to see things like CUSTOM_FPGA_XILINX | |
| 14:50:14 | Sundar_ | It is just that, without nRPs, we will apply the traits to the compute node, for Rocky cycle alone. That means, all devices on the same host must have the same traits. | |
| 14:50:37 | Sundar_ | edleafe: CUSTOM_FPGA_XILINX would be a trait on the RP, not a RC | |
| 14:50:39 | shaohe_feng | CUSTOM_FPGA_XILINX is resource or traits? | |
| 14:50:55 | edleafe | We are still hoping to have NRP complete in Rocky | |
| 14:51:02 | Sundar_ | shaohe: trait, not RC | |
| 14:51:25 | edleafe | ah, that wasn't clear. In context I thought you were using it as an RC | |
| 14:51:39 | Sundar_ | edleafe: I understand, but with 2 months left to go, I think we are risking Cyborg's Rocky goals by waiting further | |
| 14:52:42 | edleafe | Sure, that's understandable. I just want to make sure you know that that will make moving to an NRP design later harder | |
| 14:53:08 | Sundar_ | What makes the switch to nRPs hard? | |
| 14:53:54 | Sundar_ | The set of RCs and traits will stay the same. But we will apply the traits to individual device RPs later | |