| *** openstackgerrit has joined #openstack-cyborg | 01:23 | |
| openstackgerrit | Xinran WANG proposed openstack/cyborg master: Introduce quota_usage and reservation table to Cyborg https://review.openstack.org/564968 | 01:23 |
|---|---|---|
| *** masber has joined #openstack-cyborg | 02:09 | |
| *** masuberu has joined #openstack-cyborg | 02:52 | |
| openstackgerrit | Xinran WANG proposed openstack/cyborg master: Introduce quota_usage and reservation table to Cyborg https://review.openstack.org/564968 | 02:52 |
| *** masber has quit IRC | 02:52 | |
| openstackgerrit | Xinran WANG proposed openstack/cyborg master: Introduce Cyborg Resource Quota -- Usage Part https://review.openstack.org/560285 | 02:54 |
| *** masuberu has quit IRC | 04:47 | |
| *** alex_xu has quit IRC | 12:29 | |
| *** alex_xu has joined #openstack-cyborg | 12:36 | |
| *** sundar has joined #openstack-cyborg | 13:57 | |
| *** Li_Liu has joined #openstack-cyborg | 14:02 | |
| *** shashaguo has joined #openstack-cyborg | 14:03 | |
| *** dolpher has joined #openstack-cyborg | 14:07 | |
| *** Helloway has joined #openstack-cyborg | 14:08 | |
| *** shaohe has joined #openstack-cyborg | 14:09 | |
| shaohe | hi all. | 14:10 |
| *** xinran_ has joined #openstack-cyborg | 14:10 | |
| zhipengh[m] | We don't have meeting today | 14:11 |
| *** alex_xu has quit IRC | 14:11 | |
| zhipengh[m] | You didn't see the email :P | 14:11 |
| Li_Liu | #info Li_Liu | 14:11 |
| Li_Liu | I didn't | 14:11 |
| xinran_ | what mail | 14:11 |
| sundar | Hi Li_Liu, can we chat a bit? | 14:11 |
| jiapei | Good evening | 14:12 |
| Li_Liu | sure | 14:12 |
| zhipengh[m] | lol | 14:12 |
| Li_Liu | you wanna chat here? | 14:12 |
| Li_Liu | sundar | 14:12 |
| zhipengh[m] | No meeting today , but feel free to chat :) | 14:13 |
| sundar | Li_Liu: For the FPGA bitstreams, we plan to use Glance properties | 14:14 |
| sundar | Your spec referes to a table. That is a table in Cyborg, right? | 14:14 |
| 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:17 |
| *** alex_xu has joined #openstack-cyborg | 14:17 | |
| Li_Liu | Sundar | 14:20 |
| sundar | Hi Li_Liu | 14:20 |
| Li_Liu | For the Glance properties. It's not a table in Cyborg | 14:21 |
| Li_Liu | I am re-using the table in Glance | 14:21 |
| sundar | Are you proposing to add it to Glance? | 14:21 |
| Li_Liu | nope | 14:21 |
| sundar | Cyborg can use glaceclient to create and query properties | 14:22 |
| sundar | *glanceclient | 14:22 |
| Li_Liu | I am just defining what should be in that table if it's meant for a bitstream | 14:22 |
| 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:22 |
| Li_Liu | you are right | 14:23 |
| Li_Liu | We are not changing anything in the Glance space | 14:23 |
| 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 |
| Li_Liu | hmm. ok I can make according changes | 14:24 |
| sundar | Cool, thanks. | 14:24 |
| sundar | Also, having fields for 'shell' makes me concerned. Today, we use shell. But there is no guarantee that all products tomorrow | 14:24 |
| sundar | ... will also use a shell | 14:25 |
| sundar | There are lots of FPGA products out there, and somebody may want to make a service out of them | 14:25 |
| Li_Liu | but I think for at least Xilinx/Altera fpga, we are following such scheme | 14:28 |
| Li_Liu | that field is also optional | 14:28 |
| Li_Liu | user can totally ignore it | 14:29 |
| 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 |
| *** alex_xu has quit IRC | 14:29 | |
| sundar | The spec says: "Required shell bs-uuid for this bitstream" | 14:29 |
| sundar | What we really need is 3 separate fields: shell, region type UUID, function type UUID. | 14:30 |
| Li_Liu | oh, for that | 14:30 |
| sundar | The shell ID is presumably used by the proposed API to update shell logic, presumably | 14:31 |
| sundar | The region type UUID is what is matched by the bitstream. A bitstream is synthesized for a specific region type | 14:31 |
| 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:31 |
| sundar | OK, Thanks for clarifying that the shell-id is optional | 14:32 |
| sundar | Can we add a region type UUID and a function type UUID also? | 14:32 |
| sundar | We need region type for matching the bitstream to the region type | 14:33 |
| shaohe | zhipengh[m]: Li_Liu: sundar: can cyborg manage MK-TME? https://en.wikichip.org/wiki/x86/tme | 14:33 |
| *** openstackgerrit has quit IRC | 14:34 | |
| sundar | ZHipeng: there are many aspects to MKTME (and SGX). Some are clearly within Cyborg's reach. For others, I need to investigate | 14:35 |
| Li_Liu | sundar: the problem is where are these region types pointing to? | 14:36 |
| Li_Liu | are they pointing to another bitstream image? | 14:37 |
| 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:37 |
| sundar | Each bitstream corresponds to a single region type, so the metadata need only identify one region type UUID | 14:38 |
| Li_Liu | I see you point. | 14:38 |
| 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:39 |
| 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 |
| Li_Liu | until the bs program driver would figure it out | 14:40 |
| Li_Liu | let's say you have shell A with 2 region c and d | 14:41 |
| zhipengh[m] | Is there a hardware for tme ? | 14:41 |
| zhipengh[m] | From wiki it looks like an instruction set ? | 14:41 |
| sundar | Zhipeng: are you propsoing to extend Cyborg to SGX/TME, outside of accelerators? | 14:42 |
| Li_Liu | and you are loading bs B into Ac region | 14:42 |
| zhipengh[m] | Nope | 14:43 |
| zhipengh[m] | That's why I asked the question | 14:43 |
| 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 |
| 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 |
| Li_Liu | and the program driver will load the bs B into the right region | 14:43 |
| sundar | Li_Liu: please look at the use cases I defined in the CYborg/Nova spec | 14:44 |
| sundar | Zhipeng: yes, it is an instruction set, together with other hardware mechanisms. I am not aware of any device to handle it. | 14:46 |
| sundar | Zhipeng: Sorry if I am vague: I don't know how much is publicly known already :) | 14:48 |
| zhipengh[m] | Then that might be out of our scope | 14:48 |
| zhipengh[m] | Understood :) | 14:48 |
| sundar | Is anybody asking Cyborg to support it? If so, we can probably ask for time to investigate? | 14:49 |
| Li_Liu | sundar, you are saying when user doesn't know which bs they are trying to load at first place. but trying to find a region first then map to a usable bs on that region | 14:50 |
| Li_Liu | am I right? | 14:50 |
| sundar | Li_Liu: Users will not know about shell in general. The operator can broadly define 2 kinds of flavors: A. Flavor asks for a specific region type and optionally a bitstream. We call this Device as a Service. Nova finds a region of that type, and Cyborg programs it, before the VM comes up. | 14:52 |
| sundar | B. The flavor asks for a function ID and a device trait (e.g. Intel Arria 10), not a region type. Nova finds all devices of that type, which may contain different region types. | 14:53 |
| sundar | We call this Accelerated Function as a Service. Intel is interested in both use cases (and their variants). | 14:54 |
| Li_Liu | ah, I see | 14:54 |
| Li_Liu | I can surely add those two. then the one who is uploading the bs needs to figure out all of these information then | 14:55 |
| sundar | Li_Liu: yes. We can have an Cyborg API which accepts a bitstream, ensures required metadata, validates optional metadata and then uploads to Glance | 14:56 |
| Li_Liu | Thanks a lot for the suggestions | 14:57 |
| Li_Liu | so this meeting turns out to be a FFA discussion :) | 14:58 |
| sundar | Li_Liu: FFA? | 14:58 |
| Li_Liu | free for all | 14:58 |
| sundar | lol, yes it was FFA | 14:59 |
| sundar | Hope to make more discussions with you to make sure we are headed in the same direction :) | 15:00 |
| sundar | *have more | 15:00 |
| Li_Liu | sure anytime :) | 15:00 |
| zhipengh[m] | EMFA | 15:02 |
| shaohe | sundar: zhipengh[m]: Li_Liu: I means the KeyID management instead the TME, that libvirt's thing. | 15:07 |
| shaohe | but keyID seems not a acceleration, but it is a resource. | 15:07 |
| *** alex_xu has joined #openstack-cyborg | 15:07 | |
| zhipengh[m] | Yes that would be problematic | 15:15 |
| *** shashaguo has quit IRC | 16:12 | |
| *** xinran_ has quit IRC | 16:20 | |
| *** Helloway has quit IRC | 16:22 | |
| *** sundar has quit IRC | 16:44 | |
| -openstackstatus- NOTICE: The Gerrit service at review.openstack.org will be offline starting at 20:00 (in roughly 25 minutes) for a server move and operating system upgrade: http://lists.openstack.org/pipermail/openstack-dev/2018-May/130118.html | 19:35 | |
| -openstackstatus- NOTICE: The Gerrit service at review.openstack.org will be offline over the next 1-2 hours for a server move and operating system upgrade: http://lists.openstack.org/pipermail/openstack-dev/2018-May/130118.html | 20:03 | |
| *** ChanServ changes topic to "The Gerrit service at review.openstack.org will be offline over the next 1-2 hours for a server move and operating system upgrade: http://lists.openstack.org/pipermail/openstack-dev/2018-May/130118.html" | 20:03 | |
| *** Li_Liu has quit IRC | 20:48 | |
| *** ChanServ changes topic to "OpenStack Cyborg Project Discussion" | 22:08 | |
| -openstackstatus- NOTICE: Gerrit maintenance has concluded successfully | 22:08 | |
| *** mnaser_ has joined #openstack-cyborg | 23:09 | |
| *** mnaser has quit IRC | 23:16 | |
| *** mnaser_ is now known as mnaser | 23:16 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!