| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-05-14 | |||
| 11:13:28 | openstackgerrit | Yikun Jiang proposed openstack/cyborg master: Remove the old generic driver https://review.opendev.org/658986 | |
| 11:28:19 | openstackgerrit | Yikun Jiang proposed openstack/cyborg master: Add the new generic driver https://review.opendev.org/658987 | |
| #openstack-cyborg - 2019-05-15 | |||
| 02:54:04 | Sundar | Cyborg weekly IRC call in 8 min | |
| 02:54:19 | Sundar | Make it 6 min | |
| 02:59:54 | Sundar | Hi Xinran | |
| 03:00:27 | xinranwang | Hi Sundar | |
| 03:00:34 | Sundar | Will wait for 2 min for folks to join | |
| 03:00:41 | Li_Liu | HI guys | |
| 03:00:45 | Sundar | Hi Li | |
| 03:00:55 | Li_Liu | I am in China right now | |
| 03:01:03 | wangzhh | Hi all. | |
| 03:01:10 | Sundar | Hi wangzhh | |
| 03:01:35 | Sundar | Coco said she can't make it. Let's get started then | |
| 03:01:43 | Sundar | #startmeeting openstack-cyborg | |
| 03:01:44 | openstack | Meeting started Wed May 15 03:01:43 2019 UTC and is due to finish in 60 minutes. The chair is Sundar. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 03:01:45 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 03:01:47 | openstack | The meeting name has been set to 'openstack_cyborg' | |
| 03:01:52 | Sundar | #topic Roll call | |
| 03:01:54 | Li_Liu | #info Li_Liu | |
| 03:02:02 | wangzhh | #info wangzhh | |
| 03:02:03 | Sundar | #info Sundar | |
| 03:02:03 | xinranwang | #info xinranwang | |
| 03:02:17 | ikuo_o | #info ikuo_o | |
| 03:02:24 | wangzhh | Hi ikuo_o. | |
| 03:02:35 | ikuo_o | Hi wangzhh. | |
| 03:02:43 | Sundar | Please see agenda for today at: https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting | |
| 03:02:58 | Sundar | Does anybody have anything else to add to it? | |
| 03:03:25 | ikuo_o | Thanks Sundar. | |
| 03:03:54 | Sundar | #topic Cyborg specs reviews | |
| 03:04:02 | Yumeng | #info Yumeng | |
| 03:04:07 | Yumeng | Hi all | |
| 03:04:30 | Sundar | Hi Yumeng | |
| 03:04:35 | wangzhh | Morning Yumeng. | |
| 03:04:37 | Sundar | Top 4 specs in: https://review.opendev.org/#/q/status:open+project:openstack/cyborg-specs | |
| 03:05:16 | Sundar | Can we get these 4 reviewed over the next few days? | |
| 03:05:26 | ikuo_o | I and my colleagues are checking "Specification for Cyborg APIs Version 2". | |
| 03:05:31 | Li_Liu | I will try my best | |
| 03:05:44 | Sundar | Thanks, ikuo_o, Li_Liu. | |
| 03:05:50 | wangzhh | Sure. | |
| 03:06:15 | Sundar | Great. Thanks wangzhh | |
| 03:06:23 | Sundar | #topic Nova spec review | |
| 03:06:43 | Sundar | Lots of discussion in https://review.opendev.org/#/c/603955/ | |
| 03:06:56 | Li_Liu | lol | |
| 03:07:02 | Li_Liu | a lot of comments | |
| 03:07:27 | Sundar | Does Huawei want a standard accelerator name for Ascend? | |
| 03:07:35 | Sundar | Only FPGA and GPU for now | |
| 03:07:46 | Li_Liu | Yes | |
| 03:07:58 | Li_Liu | Ascend is on our agenda | |
| 03:08:25 | Li_Liu | Does it need to be mentioned in the nova spec? | |
| 03:08:30 | Sundar | Li_iu: Good. Just to be sure, instead of CUSTOM_ASCEND, you want ASCNED to be added to os-resource-classes, right? | |
| 03:08:51 | Li_Liu | you can check this with Yikun | |
| 03:08:55 | Sundar | Yes, efried has said that explicitly. | |
| 03:09:13 | yikun | #info Yikun | |
| 03:09:25 | Sundar | Hi Yikun, just in time :) | |
| 03:09:32 | yikun | sorry for late | |
| 03:10:23 | Sundar | NP. For Ascend, can we use a custom resource class name like CUSTOM_ASCEND? Or do you want to standardize it? We are standardizing only FPGA and GPU as of now | |
| 03:11:59 | wangzhh | Is 'Ascend' popular like GPU or FPGA? | |
| 03:12:16 | ikuo_o | I don't know much about ascend... | |
| 03:12:30 | yikun | FPGA GPU is the device type, but ascend maybe is not a standard type just a series, so I think maybe ascend should be cover in some thing like TPU_ASCEND or something | |
| 03:12:52 | Sundar | Perhaps it is best to leave it as a custom RC for now. | |
| 03:12:54 | Li_Liu | TPU is very google specific | |
| 03:13:08 | yikun | sorry, NPU | |
| 03:13:18 | Sundar | If we propose a standard name, it should be added to the spec, justified and also proposed as a Nova patch. | |
| 03:13:31 | Sundar | yikun, I believe you have an AI chip and a security-related accelerator? | |
| 03:14:08 | Sundar | NPU can also mean Network processing Unit. NNP = neural network processor | |
| 03:14:41 | yikun | for now, only AI chip, security-related accelerator comes from intel qat. | |
| 03:15:47 | Sundar | yikun: OK. You can think about it. I am hoping to converge the Nova spec by May end, while we still have the momentum and attention. | |
| 03:16:06 | yikun | Sundar: ok, sure | |
| 03:16:21 | Sundar | #topic Pilot merge plan | |
| 03:16:48 | Sundar | I understand some of you find the merged patch to be very large to review. Is that the reason why we are not getting many reviews? | |
| 03:18:27 | Sundar | Another way of asking: can you all review the code soon, or suggest ways to get the reviews done? | |
| 03:18:29 | Sundar | :) | |
| 03:19:02 | Li_Liu | btw, regarding changing from polling to event driven between nova and Cyborg, I just modify based on the pilot branch right? | |
| 03:19:20 | Li_Liu | or submit a seperated patch? | |
| 03:20:05 | Sundar | Li_Liu: I am using the pilot code for various demos from now till mid-June. It will be best not to disrupt the pilot patches. | |
| 03:20:06 | wangzhh | I'm fine with big patch or smaller one. | |
| 03:21:01 | Li_Liu | Sundar, sure, I will keep it clean in a different patch | |
| 03:21:29 | Sundar | Li_Liu and all: I am bit worried about what Nova guys are suggesting: there is no quantitative data on how it will affect Cyborg, right? FPGA programming can take a few seconds, and we are reducing that window of wait if we move the bind to the compute node | |
| 03:21:32 | Li_Liu | for now I will try to review the spec and pilot branch | |
| 03:21:56 | wangzhh | Li_liu, submit a seperated patch is OK. And pls add sundar's commit as a dependence. | |
| 03:22:31 | Sundar | We should try to get some idea of how much the window gets reduced in different scenarios, like launch 1 VM, launch 2 VMs together, etc. | |
| 03:23:48 | Sundar | The original suggestion at Stein PTG to do it this way was for multiple VM case. It was from Dan Smith, but he hasn't weighed in on thhe current round of dicussion | |
| 03:24:43 | Li_Liu | Are they blocking the spec merging? | |
| 03:24:57 | Yumeng | :Sundar, we only have 3 patches now, right? https://review.opendev.org/#/q/status:open+project:openstack/cyborg+branch:feature/cyborg-nova-pilot+topic:cyborg-nova-pilot | |
| 03:25:11 | Yumeng | if no more objections , we can merge asap | |
| 03:25:33 | Sundar | Well, John is saying that we either do it the way he suggests or justify doing it the current way. I don't have data either way. | |
| 03:26:31 | Sundar | Li_Liu: will you be putting a Nova patch too? | |
| 03:26:55 | Li_Liu | there will be changes in NOVA for sure | |
| 03:27:31 | Sundar | You can submit that as a separate patch too. I can try to do some measurements in a live system with the combined set before we decide fully. | |
| 03:27:40 | Li_Liu | ok | |
| 03:28:45 | Sundar | Yumeng: It is really just https://review.opendev.org/626057 . | |
| 03:29:46 | wangzhh | Yikun and I still have some comments. | |
| 03:30:14 | Sundar | wangzhh: Good. Please go ahead with the comments. | |
| 03:30:37 | Sundar | I will also add some UT. | |
| 03:31:07 | wangzhh | Great. | |
| 03:31:43 | Sundar | Also, the pilot code makes some changes to the db schema. Just raising that point, if it wasn't clear. | |
| 03:32:34 | Sundar | Networked FPGAs may make further changes but, unfortunately, I don't have full clarity on that yet. | |
| 03:33:09 | Sundar | BTW, I found this doc on db migration: https://docs.openstack.org/glance/latest/contributor/database_migrations.html | |
| 03:33:42 | Sundar | It talks of migration with expansion, contraction, etc. We aren't doing that, right? | |
| 03:34:28 | xinranwang | Btw, I trying to figure out placement report things, thers is one concern which is, the conductor will only receive the driver_device object with all infos insides. So conductor need to parse it to get the deployable, attribute etc. is it reasonable? | |