| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-05-30 | |||
| 14:41:57 | Li_Liu | entire FPGA sorry :( | |
| 14:42:38 | Sundar | Sure. By clean room environment, do you mean bare-metal instances for development? | |
| 14:44:20 | shaohe_feng | Li_Liu, do you means is a VM just own a region, it does not be allowed to do program except it own the whole FPGA? | |
| 14:44:33 | Li_Liu | hmm, IMO developer/user might not even care/sense this. All they care is I submit my rtl and it passed all the sanity test | |
| 14:45:01 | Li_Liu | shaohe_feng we are not there yet | |
| 14:46:24 | Li_Liu | after the sanity test, the synthesized bitstream is allowed to be loaded on the PR/FPGA | |
| 14:47:58 | Sundar | What is the sanity test? Checking for power issues depends on workloads and dynamic conditions | |
| 14:50:03 | Li_Liu | Sundar, as least the sanity test should check the rlt for security concerns | |
| 14:50:46 | shaohe_feng | Sundar, Li_Liu, the scenario, a tenant by a VM from cloud provider, he want this VM as his development evn, which means he will do his RTL iterative development in this VM | |
| 14:50:51 | Li_Liu | to identify any malicious behavior | |
| 14:52:29 | shaohe_feng | so there will be error during his development. | |
| 14:53:19 | Li_Liu | shaohe_feng, I agree. | |
| 14:54:57 | Li_Liu | Cloud might also want to provide Synthesis as a Service/Sanity Test as a Service | |
| 14:55:36 | Li_Liu | this we all the bitstream that are being loaded on the FPGA are gated by these services | |
| 14:56:23 | shaohe_feng | yes. | |
| 14:59:14 | Li_Liu | I am not sure if Synthesis as a Service/Sanity Test as a Service will be in the Cyborg Scope. But I think all the cloud operator should definitely consider them | |
| 14:59:56 | shaohe_feng | Sundar, what's your opinion? | |
| 15:01:22 | Sundar | Yes, cloud operators need to do 'something'. That often runs into conflict with two things: (a) bitstream developers often want confidentiality, (b) it is tough to take a bitstream (or even a post-fit netlist) and check whether it is 'good' | |
| 15:01:56 | Sundar | I suspect there is no silver bullet, and the answer will be some combination of technology and business practices | |
| 15:02:57 | Sundar | Anyways, the other big question was: how does the VM initiate programming? | |
| 15:03:54 | Li_Liu | I agree, point b is rather complicated. | |
| 15:04:12 | shaohe_feng | Sundar, does the user need to push his image to glance, let cyborg do the program or he do the program in his local VM? | |
| 15:04:20 | Li_Liu | currently, our in house implementation is using REST calls | |
| 15:04:35 | Li_Liu | to call the reprogramming service api | |
| 15:04:44 | Sundar | One way is to let the VM have access to programming the FPGA directly. Another way is to have the VM generate the request and let it come to Cyborg. There are 2 ways to do that, both with pros and cons. | |
| 15:05:51 | Sundar | Shaohe: both models are possible. The main question is, is the developer/tenant ok with sharing his bitstreams with the cloud provider? If so, we can upload it to Glance first | |
| 15:05:53 | Li_Liu | yes, we can provide both capabilities depends on senario | |
| 15:06:16 | Li_Liu | use the 1st way when user owns the BM and entire FPGA | |
| 15:06:27 | Li_Liu | use 2nd way elsewhere | |
| 15:07:14 | Sundar | Li_Liu: Sure. One way is for the VM to invoke Cyborg REST API and target the region assigned to it. Another way is for the VM to have a connection to host e.g. virtio-serial. That way, the bitstream from the VM is not going through many network paths before coming back to the host | |
| 15:08:00 | Li_Liu | We did consider the virtio-serial way | |
| 15:08:07 | Sundar | It also requires less knowledge on the VM's part: it only sends the bitstream ID or the bitstream itself, and Cyborg will target the region assigned to the VM. The VM need not know which region is assigned to it | |
| 15:08:34 | Sundar | Li_Liu: Cool. What is your evaluation of virtio-serial? | |
| 15:08:43 | Li_Liu | but the problem is in order to control the access on who can program the FPGA, the host still need to contact Cyborg anyways | |
| 15:09:07 | Sundar | Well, the Cyborg agent on the host can listen to virtio-serial | |
| 15:09:24 | Li_Liu | so the flow becomes virtio-serial --> Host --> Rest Call --> Cyborg --> access check --> Host --> Program | |
| 15:09:26 | Sundar | May be it is multi-threaded, or has helper daemons, for scalability | |
| 15:10:01 | Sundar | We don;t need REST API in this 2nd flow. The request via virtio-serial is acted upon by the Cyborg agent | |
| 15:10:11 | Li_Liu | it does not save too much network access but make the flow rather complecated | |
| 15:10:52 | Li_Liu | But the Agent needs to download the bitstream from glance | |
| 15:11:07 | Sundar | Are you assuming that REST API is involved, even with virtio-serial? If not, it is a simple 1-hop without TCP/IP networking | |
| 15:11:13 | Li_Liu | and glance needs to check if this user can use this specific bitstream | |
| 15:11:44 | Li_Liu | I think is real use case, you can not avoid REST calls | |
| 15:11:56 | Li_Liu | This is a cloud environment after all | |
| 15:12:28 | Sundar | Li_Liu: true. Either the VM provides the bitstream, which is validated for authenticity/encryption in some way. Or, the VM request refers to a bitstream id in glance | |
| 15:13:12 | Sundar | Li_Liu: "you can not avoid REST calls" Why is that? For checking whether the tenant has privileges? | |
| 15:14:37 | Li_Liu | One of the methodologies is not to allow use send a bitstream to load directly | |
| 15:15:39 | Li_Liu | this is case, the bitstreams are either coming from Glance, or from a synthesis server | |
| 15:16:32 | Li_Liu | we don't want to allow the use send a unkown bitstream through virtio-serial and blindly A | |
| 15:16:40 | Li_Liu | load it to the FPGA | |
| 15:17:02 | Sundar | Oops, running late for my next meeting. Good discussion. :) I'll check back here as much as I can. | |
| 15:17:27 | Li_Liu | actully, I gotta run as well... I am still on vacation... | |
| 15:18:05 | Li_Liu | shaohe_feng, could you terminate the meeting and log the conversation, we can pick it up later | |
| 15:20:40 | shaohe_feng | OK. we can discuss more about it next time. | |
| 15:21:00 | shaohe_feng | #topic docs | |
| 15:21:13 | shaohe_feng | we need to improve cyborg docs. | |
| 15:21:44 | shaohe_feng | I have update the wiki https://wiki.openstack.org/wiki/Cyborg#How_to_contribute | |
| 15:21:48 | shaohe_feng | add DevStack Quick Start link to the wiki | |
| 15:21:55 | shaohe_feng | so New contributors can follow it setup their cyborg env. | |
| 15:22:00 | shaohe_feng | Any issue during the setup, they can fix it and feedback to community. | |
| 15:22:04 | Li_Liu | I will try to work on it with couple other folks in doc tesam | |
| 15:22:23 | shaohe_feng | Li_Liu, good, thanks. | |
| 15:22:41 | shaohe_feng | AoB? | |
| 15:23:48 | shaohe_feng | OK, let's end the meeting. | |
| 15:23:50 | shaohe_feng | #endmeeting | |
| 15:24:17 | shaohe_feng | #endmeeting | |
| 15:24:31 | shaohe_feng | bye. | |
| 15:26:38 | sum12 | i think start meeting was not considered as there was space before startmeeting :) | |
| 15:27:24 | Li_Liu | lol | |
| 15:45:25 | shaohe_feng | #endmeeting | |
| 15:46:58 | shaohe_feng_ | #endmeeting | |
| 22:04:40 | openstackgerrit | Sundar Nadathur proposed openstack/cyborg master: Specification for Cyborg/Nova interaction for scheduling. https://review.openstack.org/554717 | |
| #openstack-cyborg - 2018-05-31 | |||
| 02:32:26 | openstackgerrit | Merged openstack/cyborg master: Added attribute object and its unit tests https://review.openstack.org/565382 | |
| #openstack-cyborg - 2018-06-04 | |||
| 11:22:04 | openstackgerrit | wangzhh proposed openstack/cyborg master: Fix Deployable get_by_host https://review.openstack.org/572080 | |
| 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. | |