Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2018-08-01
15:13:47 efried ^ use case for truly ad hoc traits even in a "cattle" environment.
15:16:25 Sundar efried and all: A process question: how can we ensure that we have got all requirements and that the next round of spec updates shall be adequate to start implementation for Stein? We had a bunch of plans for Rocky and we want to ensure they are delivered in Stein. Open to ideas!
15:16:54 efried Sundar: If you solve that one, you get a Nobel.
15:18:04 Li_Liu rofl
15:18:06 efried But the neat thing about our process is that it doesn't have to be perfect and fully-formed the first time around.
15:18:29 efried You put out *something* and then improve on it incrementally.
15:18:47 efried Surely you didn't think you were going to be done after one release.
15:18:49 Li_Liu workable -> usable
15:20:31 Sundar :) Shall we define a date before Stein's last spec approval date, by which time we can review and approve the needed Cyborg specs, and get started on implementation after that?
15:21:23 Sundar If any stakeholder wants an update after that, we can address that in T release
15:22:14 Sundar Oct 22-26 is Stein Milestone 1.
15:22:24 Sundar That is 3 months away
15:22:51 Sundar I suspect we can get the specs done in 1 month if we put our collective minds to it. Comments?
15:23:56 efried Just to level set, a statement like ^ is true in isolation, but you can't guarantee that all the stakeholders will have the time to dedicate to it to make that timeline feasible.
15:24:09 efried That said, I will do what I can to carve out the time.
15:24:52 Sundar Thanks, Eric.
15:25:35 Sundar To elaborate, if we wait until Oct end, we get very little time for implementation given that Dec and 1st half Jan are usually in holiday mode
15:26:12 Sundar Anyways, I'll take an AR to read the spec you mentioned, and update the specs on traits etc.
15:26:30 xinran__ So did we have a solution about how to map function uuid to name, or other things like that?
15:27:16 Sundar On UUID/name maps, whether that should come from the bitstream developer or the operator is an open question. The UUID itself comes the bitstream developer
15:28:01 Sundar If the driver is going to define traits, that is another wrinkle because the driver comes from the device vendor, which is yet another role
15:28:50 Sundar So, we need to have some input on how people use this in practice -- feedback needed from operators, bitstream developers etc.
15:29:39 Sundar I think this needs to be solved -- we should go to names, but any premature move before people understand and use Cyborg may require fixing later -- and that can be messy with upgrade issues wtc
15:32:21 Sundar Can we stick to UUIDs for now, and take up the name translation in subsequent discussion? That is the lowest common denominator anyway.
15:33:40 efried sorry, uuids/names for what specifically?
15:33:41 xinran__ Is it possible to translate the uuid to name in cyborg according to the data structure got by driver?
15:33:48 Li_Liu sure, that requires less modifications in the future I think
15:35:07 Li_Liu xinran__, those uuid are reported by drivers, Cyborg needs to track them
15:35:11 Sundar Xinran: as I explained, we have to ask should define function names. The driver comes from a device vendor (like Intel/Xilinx) -- they may not know anything about a specific function developed by a third party
15:35:14 Li_Liu Sundar, am i right?
15:36:08 Sundar Li_Liu: the UUIDs are reported by drivers, based on what they discover from the device itself.
15:36:20 Sundar However, where does the name came from?
15:36:38 xinran__ Yes that’s the problem
15:36:54 Li_Liu I believe name should also reported by driver
15:37:31 Li_Liu driver should know the name, and report them to Cyborg
15:37:47 Sundar There are two options: have the bitstream developer define an optional name (the current metadata spec already provides for it), or have the cloud operator define a UUID/name map like Shaohe mentioned
15:37:52 xinran__ How does driver know the name?
15:37:56 Sundar Both have their pros and cons.
15:39:27 Sundar The driver does not know any function names in the general case. If the driver itself is involved in programming a bitstream and the bitstream metadata has a name, well and good. But, the device may be pre-programmed or the bitstream many not have that metadata
15:39:44 Li_Liu driver gets the name from either: 1. device information read from hardware. 2. When loading a bitstream, driver can decode the name from the image file
15:39:52 dolpher sundar: operator doest define name, they should got name from vendor, and put them into the mapping file
15:40:28 dolpher so agent or driver can read it then update to trait
15:40:44 Sundar Li_Liu: Device info from hardware does not include function names today, for any major vendor AFAIK
15:41:08 Sundar Dolpher: which vendor? Bitstream developer or device vendor?
15:41:21 Sundar Device vendors would not know about function names at all
15:41:27 Li_Liu Sundar, I know, this is totally up to vendors
15:41:27 dolpher bitsteam vendor
15:42:24 Sundar Bitstream developers can define an optional name like I said -- it is already there in the spec today. However, that may not be unique! Two different bitstreams can both say they are doing gzip
15:42:45 efried is that a bad thing?
15:43:05 xinran__ Li_Liu: I think the option2 is better, when it is a pre preprogrammed card, can we get the name?
15:44:27 Li_Liu xinran__ if it's pre-programmed card, it's driver's job to figure out what to report
15:45:35 Li_Liu I mean, using a pre-programmed card is almost equivalent to using a ASIC chip
15:45:45 wangzhh Li_Liu, can driver collect the info 'name'?
15:46:27 Li_Liu imagine the case when a ASIC card is used
15:46:54 Li_Liu it has to have a dedicated driver to discovery+report
15:47:22 Li_Liu lol. there your go :)
15:48:54 xinran__ So you mean each preprogrammed card need a dedicated driver?
15:50:19 Sundar Probably the practical way out is to have the operator define the map. But that means everytime a new bitstream gets uploaded or the operator updates a pre-programmed card, the map has to be updated. This can probably be automated. We should probably let operators get the hang of Cyborg before imposing new workflows on them.
15:51:03 Li_Liu if you really wanna do that. it's driver's job to figure out the initial state of the card (which includes name as one of the initial information)
15:52:49 Sundar I need to drop out in 5 min.
15:53:30 Sundar I will update the specs. Please LMK what else do you think is missing or needs to be added to the specs.
15:53:56 efried Sundar: Please add me as a reviewer to any specs I'm not already on that you think I need to see.
15:54:04 Li_Liu I have to drop too.
15:54:15 Li_Liu Let's wrap up
15:54:17 Sundar efried: Absolutely
15:54:19 Sundar Li_Liu: Can we make it a standing agenda item to ask for spec reviews, so we can close this quickly?
15:54:32 Li_Liu ok
15:55:47 Li_Liu #todo add spec review as a standing agenda for future irc meetings
15:55:57 Li_Liu #endmeeting
15:56:00 openstack Meeting ended Wed Aug 1 15:55:57 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:56:01 openstack Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-08-01-14.11.html
15:56:02 openstack Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-08-01-14.11.txt
15:56:04 openstack Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-08-01-14.11.log.html
15:56:11 Sundar Thanks, Li_Liu!
15:56:16 Li_Liu Thanks a lot guys
15:56:24 Li_Liu Have a great nite/day
15:56:40 wangzhh Bye.
#openstack-cyborg - 2018-08-02
02:19:40 openstackgerrit wangzhh proposed openstack/python-cyborgclient master: Add filter to list https://review.openstack.org/586916
02:36:39 openstackgerrit wangzhh proposed openstack/python-cyborgclient master: Add filter to list https://review.openstack.org/586916
02:51:51 openstackgerrit Li Liu proposed openstack/cyborg master: Added rest API for FPGA programming https://review.openstack.org/579315
03:02:32 openstackgerrit wu.chunyang proposed openstack/python-cyborgclient master: update wrong link https://review.openstack.org/588125
#openstack-cyborg - 2018-08-03
09:12:04 openstackgerrit YumengBao proposed openstack/cyborg master: Docs: Autogenerate config documentation https://review.openstack.org/588480
#openstack-cyborg - 2018-08-04
03:01:45 openstackgerrit JiangGuocai proposed openstack/cyborg master: Add HPTS driver, (HPTS: High Precision Time Synhronization cards) https://review.openstack.org/586994
03:50:44 openstackgerrit JiangGuocai proposed openstack/cyborg master: Add HPTS driver, (HPTS: High Precision Time Synhronization cards) https://review.openstack.org/586994
08:51:02 openstackgerrit Hongbo_Zhao proposed openstack/cyborg master: Add interface for update flash with FPGA FIM image https://review.openstack.org/588882
#openstack-cyborg - 2018-08-05
02:35:14 openstackgerrit Li Liu proposed openstack/cyborg master: Added rest API for FPGA programming https://review.openstack.org/579315
03:20:15 openstackgerrit Li Liu proposed openstack/cyborg master: Added rest API for FPGA programming https://review.openstack.org/579315
23:46:49 openstackgerrit JiangGuocai proposed openstack/cyborg master: Add HPTS driver, (HPTS: High Precision Time Synhronization cards) https://review.openstack.org/586994
#openstack-cyborg - 2018-08-06
01:30:19 openstackgerrit Hongbo_Zhao proposed openstack/cyborg master: Add interface for update flash with FPGA FIM image https://review.openstack.org/588882
04:49:15 openstackgerrit Li Liu proposed openstack/cyborg master: Added rest API for FPGA programming https://review.openstack.org/579315
06:23:44 openstackgerrit Hongbo_Zhao proposed openstack/cyborg master: Add interface for update flash with FPGA FIM image https://review.openstack.org/588882
13:02:19 openstackgerrit JiangGuocai proposed openstack/cyborg master: Add HPTS driver, (HPTS: High Precision Time Synhronization cards) https://review.openstack.org/586994
13:13:27 openstackgerrit JiangGuocai proposed openstack/cyborg master: Add HPTS driver, (HPTS: High Precision Time Synhronization cards) https://review.openstack.org/586994
13:52:37 shaohe_feng Hi everyone
13:52:45 shaohe_feng we will hold a zoom meeting today.
13:53:01 shaohe_feng #link we will hold a zoom meeting today.
13:53:31 shaohe_feng #link https://zoom.us/j/236172152
14:01:13 edleafe shaohe_feng_: I'm curious - why the switch to zoom? I would have thought that with so many non-native English speakers that IRC would be better
14:07:06 shaohe_feng_ edleafe: It is an English zoom meeting.
14:08:14 shaohe_feng_ #startmeeting openstack-cyborg-driver

Earlier   Later