| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-04-25 | |||
| 15:21:07 | zhipeng | any other issues on this topic ? | |
| 15:22:04 | zhipeng | okey then | |
| 15:22:09 | zhipeng | #topic AoB | |
| 15:22:32 | zhipeng | any other business | |
| 15:23:31 | xinran_ | what is AoB...... | |
| 15:23:45 | xinran_ | Ah i know! | |
| 15:24:11 | zhipeng | xinran_ bien :) | |
| 15:25:07 | xinran_ | ;) | |
| 15:26:10 | zhipeng | okey if there are no other topics | |
| 15:26:17 | zhipeng | let's conclude the meeting today | |
| 15:26:28 | zhipeng | thx for the great conversation :) | |
| 15:26:31 | zhipeng | #endmeeting | |
| 15:26:33 | openstack | Meeting ended Wed Apr 25 15:26:31 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 15:26:34 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-04-25-13.59.html | |
| 15:26:35 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-04-25-13.59.txt | |
| 15:26:36 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-04-25-13.59.log.html | |
| 15:26:40 | NokMikeR | thanks all, bye | |
| #openstack-cyborg - 2018-04-27 | |||
| 07:52:24 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Introduce Cyborg Resource Quota -- Usage Part https://review.openstack.org/560285 | |
| 13:04:50 | openstackgerrit | ShaoHe Feng proposed openstack/cyborg master: bug fix: amend keyston endpoint register info https://review.openstack.org/564753 | |
| #openstack-cyborg - 2018-04-28 | |||
| 02:28:58 | openstackgerrit | wangzhh proposed openstack/cyborg master: Fix remote call conductor error https://review.openstack.org/564962 | |
| 03:36:17 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Introduce quota_usage and reservation table to Cyborg https://review.openstack.org/564968 | |
| 07:13:44 | openstackgerrit | ShaoHe Feng proposed openstack/cyborg master: bug fix: endpoint register, import and devstack broken issues. https://review.openstack.org/564753 | |
| 07:40:34 | openstackgerrit | wangzhh proposed openstack/cyborg master: Fix remote call conductor error https://review.openstack.org/564962 | |
| 10:27:17 | openstackgerrit | Merged openstack/cyborg master: Fix remote call conductor error https://review.openstack.org/564962 | |
| 10:39:22 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Introduce quota_usage and reservation table to Cyborg https://review.openstack.org/564968 | |
| 14:11:08 | openstackgerrit | ShaoHe Feng proposed openstack/python-cyborgclient master: base framework for cyborg client. https://review.openstack.org/565023 | |
| 14:15:45 | openstackgerrit | ShaoHe Feng proposed openstack/python-cyborgclient master: base framework for cyborg client. https://review.openstack.org/565023 | |
| 14:30:47 | openstackgerrit | ShaoHe Feng proposed openstack/python-cyborgclient master: base framework for cyborg client. https://review.openstack.org/565023 | |
| #openstack-cyborg - 2018-04-29 | |||
| 03:24:31 | openstackgerrit | Merged openstack/cyborg master: bug fix: endpoint register, import and devstack broken issues. https://review.openstack.org/564753 | |
| #openstack-cyborg - 2018-05-01 | |||
| 02:17:50 | openstackgerrit | Li Liu proposed openstack/cyborg master: Added attribute object and its unit tests https://review.openstack.org/565382 | |
| #openstack-cyborg - 2018-05-02 | |||
| 01:23:22 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Introduce quota_usage and reservation table to Cyborg https://review.openstack.org/564968 | |
| 02:52:31 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Introduce quota_usage and reservation table to Cyborg https://review.openstack.org/564968 | |
| 02:54:30 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Introduce Cyborg Resource Quota -- Usage Part https://review.openstack.org/560285 | |
| 14:10:05 | shaohe | hi all. | |
| 14:11:11 | zhipengh[m] | We don't have meeting today | |
| 14:11:17 | zhipengh[m] | You didn't see the email :P | |
| 14:11:18 | Li_Liu | #info Li_Liu | |
| 14:11:40 | Li_Liu | I didn't | |
| 14:11:46 | xinran_ | what mail | |
| 14:11:59 | sundar | Hi Li_Liu, can we chat a bit? | |
| 14:12:24 | jiapei | Good evening | |
| 14:12:26 | Li_Liu | sure | |
| 14:12:37 | zhipengh[m] | lol | |
| 14:12:38 | Li_Liu | you wanna chat here? | |
| 14:12:54 | Li_Liu | sundar | |
| 14:13:58 | zhipengh[m] | No meeting today , but feel free to chat :) | |
| 14:14:03 | sundar | Li_Liu: For the FPGA bitstreams, we plan to use Glance properties | |
| 14:14:40 | sundar | Your spec referes to a table. That is a table in Cyborg, right? | |
| 14:17:05 | sundar | The spec https://git.openstack.org/cgit/openstack/cyborg/commit/?id=f1355e51fe89021cdd27308829c333a98c14820b says: "For each metadata, it will be stored as a row in this Glance's image_properties in key-value pair format" | |
| 14:20:34 | Li_Liu | Sundar | |
| 14:20:50 | sundar | Hi Li_Liu | |
| 14:21:12 | Li_Liu | For the Glance properties. It's not a table in Cyborg | |
| 14:21:20 | Li_Liu | I am re-using the table in Glance | |
| 14:21:39 | sundar | Are you proposing to add it to Glance? | |
| 14:21:44 | Li_Liu | nope | |
| 14:22:02 | sundar | Cyborg can use glaceclient to create and query properties | |
| 14:22:07 | sundar | *glanceclient | |
| 14:22:15 | Li_Liu | I am just defining what should be in that table if it's meant for a bitstream | |
| 14:22:36 | sundar | If we propose a change to Glance, we should fly it by them. But, by using only the glanceclient, we should be ok | |
| 14:23:24 | Li_Liu | you are right | |
| 14:23:35 | sundar | Ok. Instead of phrasing it as rows in Glance, which is really Glance internals, we can say what properties we intend to create and query | |
| 14:23:35 | Li_Liu | We are not changing anything in the Glance space | |
| 14:24:05 | Li_Liu | hmm. ok I can make according changes | |
| 14:24:13 | sundar | Cool, thanks. | |
| 14:24:59 | sundar | Also, having fields for 'shell' makes me concerned. Today, we use shell. But there is no guarantee that all products tomorrow | |
| 14:25:07 | sundar | ... will also use a shell | |
| 14:25:34 | sundar | There are lots of FPGA products out there, and somebody may want to make a service out of them | |
| 14:28:30 | Li_Liu | but I think for at least Xilinx/Altera fpga, we are following such scheme | |
| 14:28:52 | Li_Liu | that field is also optional | |
| 14:29:09 | Li_Liu | user can totally ignore it | |
| 14:29:24 | sundar | There are plenty of Alter-based products out there that don;t use a shell. Same must be true of Xilinx too. We should not preclude them from being used in the cloud, by design | |
| 14:29:57 | sundar | The spec says: "Required shell bs-uuid for this bitstream" | |
| 14:30:27 | sundar | What we really need is 3 separate fields: shell, region type UUID, function type UUID. | |
| 14:30:33 | Li_Liu | oh, for that | |
| 14:31:03 | sundar | The shell ID is presumably used by the proposed API to update shell logic, presumably | |
| 14:31:18 | sundar | The region type UUID is what is matched by the bitstream. A bitstream is synthesized for a specific region type | |
| 14:31:20 | Li_Liu | I marked that filed as nullable=True. "Required shell bs-uuid for this bitstream" I mean if a shell is required for this bitstrea, | |
| 14:32:20 | sundar | OK, Thanks for clarifying that the shell-id is optional | |
| 14:32:40 | sundar | Can we add a region type UUID and a function type UUID also? | |
| 14:33:09 | sundar | We need region type for matching the bitstream to the region type | |
| 14:33:57 | shaohe | zhipengh[m]: Li_Liu: sundar: can cyborg manage MK-TME? https://en.wikichip.org/wiki/x86/tme | |
| 14:35:23 | sundar | ZHipeng: there are many aspects to MKTME (and SGX). Some are clearly within Cyborg's reach. For others, I need to investigate | |
| 14:36:45 | Li_Liu | sundar: the problem is where are these region types pointing to? | |
| 14:37:01 | Li_Liu | are they pointing to another bitstream image? | |
| 14:37:58 | sundar | Li_Liu: The current approach seems to assume a simple model of a shell and a single region within that. That may not remain true over time. We may want to support multiple regions in the same shell. Then, we need a separate region type UUID for each such region. When we synthesize a bitstream, its metadata would say which region type it was synthesized for | |
| 14:38:28 | sundar | Each bitstream corresponds to a single region type, so the metadata need only identify one region type UUID | |
| 14:38:59 | Li_Liu | I see you point. | |
| 14:39:19 | shaohe | zhipengh[m]: Li_Liu: sundar: For MKTME, the keyID is limitation. Cyborg can manage the keyID, for example, assign a keyID to a VM, and how multi-VM (belong to one tanent) share one keyID | |
| 14:40:41 | Li_Liu | as you said, the region type UUID is packed in bitstreams during sythesis, Cyborg shoud not care which specific region this bs is targeting | |
| 14:40:58 | Li_Liu | until the bs program driver would figure it out | |
| 14:41:29 | Li_Liu | let's say you have shell A with 2 region c and d | |
| 14:41:30 | zhipengh[m] | Is there a hardware for tme ? | |
| 14:41:46 | zhipengh[m] | From wiki it looks like an instruction set ? | |
| 14:42:00 | sundar | Zhipeng: are you propsoing to extend Cyborg to SGX/TME, outside of accelerators? | |
| 14:42:01 | Li_Liu | and you are loading bs B into Ac region | |
| 14:43:06 | zhipengh[m] | Nope | |
| 14:43:19 | zhipengh[m] | That's why I asked the question | |
| 14:43:35 | Li_Liu | Cyborg only needs to know I have a shell A some where and I am sending bs B to the coresponding host(that contains an A) | |
| 14:43:38 | sundar | Li_Liu: Cyborg needs to handle the use case where the flavor asks for a function ID and a product trait (e.g. Intel ARria 10). The scheduler picks up all the RPs with that trait, including regions of different types. Based on which region got selected, Cyborg would quey glance for a bitstream that has the function ID as its property, and also the same region type UUID as its property. | |
| 14:43:52 | Li_Liu | and the program driver will load the bs B into the right region | |