| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2020-07-02 | |||
| 03:16:02 | Yumeng | I mean, the Inspur FPGA driver and Inspur NVME SSD which you are plannig to submit. If you don't have ,I'm more impossible to have. :( | |
| 03:16:16 | brinzhang_ | just saw you response in the ML | |
| 03:16:34 | Yumeng | http://lists.openstack.org/pipermail/openstack-discuss/2020-June/subject.html | |
| 03:16:40 | Yumeng | here is more. | |
| 03:17:17 | brinzhang_ | yeah, we dont have server to support the CI evn in project planning, hope you can understand. | |
| 03:17:35 | Yumeng | maybe that will inspirs you any new ideas. | |
| 03:18:02 | brinzhang_ | Yumeng: but we can show the test results on the implements patch, should not limit the spec go | |
| 03:20:03 | Yumeng | I understand. We need thinking the third-party CI or any other workarounds, since that's a topic asked by other projects several times. | |
| 03:20:15 | brinzhang_ | Yumeng: I can understand this, but I feel helpless to provide 3rd-party CI. | |
| 03:20:49 | brinzhang_ | Yes, this requires hardware support. I think this is not just a problem we encountered at Cyborg. | |
| 03:21:34 | Yumeng | don't have to be a very serious 3rd-party CI. I think the main concern from others should be if that driver really works? or things like that | |
| 03:22:27 | brinzhang_ | If the contributor can provide a complete test report, I think it is acceptable, what do you think? | |
| 03:23:03 | brinzhang_ | maybe we shuold mark the driver lack of it's CI to run | |
| 03:23:26 | Yumeng | brinzhang_: makes sense to me! | |
| 03:24:18 | brinzhang_ | Yuemng: thanks, this is a better way I can think of. | |
| 03:24:19 | Yumeng | we publish these kind of report to potential customers (either in documentation or other ways) | |
| 03:25:53 | shaohe_feng | Hi all | |
| 03:26:07 | brinzhang_ | we publish these kind of report to potential customers (either in documentation or other ways) | |
| 03:26:11 | songwenping__ | His shaohe. | |
| 03:26:11 | Yumeng | hi shaohe_feng | |
| 03:26:35 | shaohe_feng | conflict with another meeting, sorry for late | |
| 03:26:41 | brinzhang_ | we can left comment under the under the code to implement SPEC. | |
| 03:27:28 | brinzhang_ | Two ways: one is provide the 3rd-party CI; another is proivder the complete test report for the target driver. | |
| 03:28:22 | songwenping__ | brinzhang_: What is the complete test report like? | |
| 03:29:07 | Yumeng | shaohe_feng: no worries. we were discussing if we need third-party CI for new drivers in this release. | |
| 03:29:47 | shaohe_feng | got it, thanks. | |
| 03:30:43 | brinzhang_ | The report should show the driver can run successfully, may contain each api requst/response test result | |
| 03:31:54 | Yumeng | agree. That makes sense to me now. I cannot think of any better idea for now. | |
| 03:32:02 | songwenping__ | Can u provide a template? | |
| 03:32:05 | brinzhang_ | or others result you can provide, should let the reviewer can know it's a better driver | |
| 03:32:56 | brinzhang_ | Each driver is implemented differently and cannot provide templates. Provide a test list yourself if possible. | |
| 03:33:13 | Yumeng | I think nova operations like creation, deletion are very important | |
| 03:34:36 | brinzhang_ | nova-cyborg interaction is not a mandatory requirement, and may not be called through nova. | |
| 03:35:06 | brinzhang_ | But if used, it is best to provide. | |
| 03:36:14 | Yumeng | if we have third-party CI, that's a mandatory I suppose | |
| 03:37:08 | Yumeng | current tempest only test fake driver. third-party CI test real driver. | |
| 03:37:31 | brinzhang_ | yeah, can as soon as possiable to provider the nova operaction | |
| 03:37:54 | Yumeng | so from my understanding, test report will be a make up for third-party CI. | |
| 03:38:44 | Yumeng | I can bring up a ML thread to discuss this. | |
| 03:39:22 | brinzhang_ | Yuemng: You can | |
| 03:39:33 | Yumeng | Is there any other things want to bring up for today? | |
| 03:40:17 | Yumeng | I was testing rbac policy API, will soon submit the patches. | |
| 03:40:39 | brinzhang_ | Yuemng: cool, ths | |
| 03:40:47 | brinzhang_ | Yumeng, songwenping_, shaohe_feng: I have to go now, bye~ | |
| 03:41:02 | Yumeng | if nothing else, let's wrap up today's meeting | |
| 03:41:04 | shaohe_feng | brinzhang_ bye, have a good day | |
| 03:41:12 | songwenping__ | bye | |
| 03:41:15 | Yumeng | bye | |
| 03:41:21 | shaohe_feng | Yumeng, I'd like to talk about program | |
| 03:41:29 | Yumeng | ok. sure. | |
| 03:41:33 | Yumeng | please go ahead. | |
| 03:41:41 | shaohe_feng | Now it will take about one hour for us to program FPGA. | |
| 03:42:29 | shaohe_feng | and I find the program API will report timeout | |
| 03:42:29 | Yumeng | sounds like a long time. | |
| 03:42:42 | shaohe_feng | yes, a long time | |
| 03:43:15 | s_shogo | shaohe_feng : I would like to know the FPGA spec , e.g. Arria10 GX | |
| 03:43:26 | shaohe_feng | the client wait for the API response and receive the timeout | |
| 03:43:37 | shaohe_feng | s_shogo: yes it is A10 | |
| 03:43:48 | shaohe_feng | s_shogo: but we do not program the PR | |
| 03:44:09 | shaohe_feng | we program the whole flash. | |
| 03:44:35 | s_shogo | ok, I got it. It seems to be similar to N3000 case. | |
| 03:44:40 | shaohe_feng | for PR takes so many logic units | |
| 03:44:53 | shaohe_feng | s_shogo: yes, it is N3000 | |
| 03:45:36 | shaohe_feng | It really take too long time:') | |
| 03:45:51 | shaohe_feng | can we support async program? | |
| 03:46:07 | s_shogo | I know, that takes 25-40min :) | |
| 03:46:52 | s_shogo | IMO, supporting for async program needs modification for driver, agent, and so on . That is big task. | |
| 03:46:57 | Yumeng | shaohe_feng: havewe already supported async program ?https://review.opendev.org/#/c/681005/ | |
| 03:47:00 | shaohe_feng | the program API start to program and return immediately | |
| 03:47:12 | shaohe_feng | s_shogo: yes, I know | |
| 03:47:36 | shaohe_feng | we need a new API to show the program status | |
| 03:47:45 | shaohe_feng | then user know the program process | |
| 03:47:59 | shaohe_feng | and notify mechanical | |
| 03:48:08 | shaohe_feng | for driver, agent. | |
| 03:48:24 | shaohe_feng | really big task | |
| 03:48:45 | shaohe_feng | like async bind, it is also a big task | |
| 03:49:12 | Yumeng | aha. sorry. that's async bing. | |
| 03:49:22 | Yumeng | bind | |
| 03:49:55 | shaohe_feng | s_shogo, Yumeng, any ideas on it? | |
| 03:52:11 | s_shogo | shaohe_feng I approve your idea. IMO, the async architecture should be same to async bind, for uniformity. | |
| 03:52:47 | shaohe_feng | yes, agree | |
| 03:53:18 | Yumeng | I'm not quite familar with programing. sounds like waiting such a long time is horrible. | |
| 03:53:39 | Yumeng | from this point, I would support async program | |
| 03:54:58 | Yumeng | how will that affect agent? | |
| 03:55:03 | Yumeng | agent workflow? | |
| 03:56:07 | shaohe_feng | that may be a complex case | |
| 03:56:26 | Yumeng | haha. no worries. too big question. | |
| 03:56:51 | shaohe_feng | such as during this program time | |
| 03:57:48 | shaohe_feng | a new program API is issued, the cyborg-API should know there's already one is in progress, and should reject the request | |
| 03:58:45 | Yumeng | ok. | |
| 03:59:35 | shaohe_feng | and as s_shogo in his patch say: the driver should report the program info to agent, and at last, to tell the end user | |
| 04:00:02 | shaohe_feng | such as it is successful, or failed with some reason | |
| 04:01:04 | Yumeng | alright. thanks shaohe. | |
| 04:01:27 | shaohe_feng | Yumeng, and maybe a new field in DB(or other ways) to show the program status to user. | |
| 04:01:51 | shaohe_feng | Yumeng: we should think about it. | |
| 04:02:19 | Yumeng | sounds like a huge task. | |
| 04:02:52 | shaohe_feng | yes, async means complex. | |
| 04:03:06 | Yumeng | emmm do you think we start next release？ | |
| 04:03:06 | Yumeng | emmm do you think we start next release？ | |
| 04:03:31 | shaohe_feng | we are waiting for this program API | |