Earlier  
Posted Nick Remark
#openstack-cyborg - 2018-04-25
15:16:38 zhipeng if by then we still could not get it landed, then I will block it for Rocky but could be land first thing in Stein :)
15:16:47 Li_Liu zhipeng, let me know if you need some help on that one
15:16:57 zhipeng sounds reasonable
15:16:58 zhipeng ?
15:17:06 zhipeng Li_Liu sure :)
15:17:29 Li_Liu since I think I have some thoughts on it
15:17:34 zhipeng #agreed os-acc spec extended to MS2 for approval
15:17:53 zhipeng Li_Liu no problem, feel free to share it
15:18:04 zhipeng okey moving on
15:18:14 zhipeng #topic open patches/bugs
15:18:31 zhipeng I will push up the fix for mutable-config this week
15:20:16 zhipeng maybe combined with the fix lenovo folk has provided but blocked by me due to trivial fix
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 Li_Liu We are not changing anything in the Glance space
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: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

Earlier   Later