| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-08-01 | |||
| 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 | |
| 14:08:15 | openstack | Meeting started Mon Aug 6 14:08:14 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:08:16 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 14:08:17 | edleafe | I understand. Many non-native speakers, though, have told me that it is easier for them to type in English than speak it | |
| 14:08:20 | openstack | The meeting name has been set to 'openstack_cyborg_driver' | |
| 14:11:02 | shaohe_feng_ | So let's have the meeting both by zoom and IRC. | |
| 14:12:01 | shaohe_feng_ | #link https://zoom.us/j/236172152 | |
| 14:14:20 | shaohe_feng_ | edleafe: Many developers think zoom may be more efficient. let's have a try on zoom. | |
| 14:15:26 | edleafe | It's fine with me :) | |
| 14:17:13 | shaohe_feng_ | efried: #link https://zoom.us/j/236172152 Today, coco will introduce her new driver design. | |
| 14:17:45 | efried | shaohe_feng_: is this happening right now? | |
| 14:18:38 | edleafe | efried: yes | |
| 14:26:18 | shaohe_feng_ | #link https://etherpad.openstack.org/p/cyborg-rocky-development | |
| 15:09:39 | shaohe_feng_ | #action sunwill update the spec https://review.openstack.org/#/c/561849/ | |
| 15:10:00 | shaohe_feng_ | #action Sundar will update the spec https://review.openstack.org/#/c/561849/ | |
| 15:40:47 | shaohe_feng_ | How update the DB schema to reflect acc info changes from driver. | |
| 15:41:15 | shaohe_feng_ | Sunder's suggestions as follow: | |
| 15:41:31 | shaohe_feng_ | The agent should send the diff to the conductor. The conductor updates the DB and then updates placement. Reasons: * If the conductor does the diff, it can become the scalability bottleneck. The agent needs to store the previous config in local host. * It is more efficient for the agent to make one RPC call than many separate calls once for each deployable, trait etc. The diff include a new acc on line or a exi | |
| 15:41:56 | shaohe_feng_ | The agent should send the diff to the conductor. The conductor updates the DB and then updates placement. Reasons: | |
| 15:42:09 | shaohe_feng_ | * If the conductor does the diff, it can become the scalability bottleneck. The agent needs to store the previous config in local host. | |
| 15:42:17 | shaohe_feng_ | * It is more efficient for the agent to make one RPC call than many separate calls once for each deployable, trait etc. | |
| 15:42:37 | shaohe_feng_ | The diff include a new acc on line or a exist acc off line? | |
| 15:42:52 | shaohe_feng_ | Yes. Also, changes to existing devices. | |
| 15:42:59 | shaohe_feng_ | Then how does agent to present these diff? | |
| 15:43:14 | shaohe_feng_ | It needs to indicate the list of added devices, the list of deleted ones, and the list of modified ones. How we indicate the modifications to existing devices is open to q. :) | |
| 15:43:30 | shaohe_feng_ | Yes， modification is more complex than others(add/delete) | |
| 15:43:40 | shaohe_feng_ | Agreed. That's why I thought it is easier for the conductor to do the diff, because it can compare the db fields, field by field | |
| 15:43:50 | shaohe_feng_ | But, for the agent to send it, it should send a dictionary that also indicates what got added, deleted or changed for an existing device. | |
| 15:43:59 | shaohe_feng_ | E.g. a region got programmed, so the function type trait changed. So, the diff must indicate the old function type trait must be deleted, and a new one added | |
| 15:58:20 | shaohe_feng_ | #endmeeting | |
| 15:58:22 | openstack | Meeting ended Mon Aug 6 15:58:20 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |