| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-07-30 | |||
| 16:25:49 | efried | What are their respective responsibilities and roles? | |
| 16:26:46 | Sundar_ | Ah, good question. When you first proposed a plugin, I thought you knew about Cyborg drivers already, and still wanted another mechanism. Anyways, here's how I look at it ... | |
| 16:28:10 | Sundar_ | Both plugins and drivers represent ways to handle vendor/device/hypervisor/architecture-specific aspects that should not be in core Cyborg or os-acc. | |
| 16:29:23 | Sundar_ | There are two ways that os-acc can interact with Cyborg. (a) Leave most of the work to Cyborg: then the drivers are the main extensibility mechanism. (b) Leave only device-specific aspects to Cyborg and hypervisor and other aspects to the plugin. | |
| 16:30:38 | Sundar_ | One possible way to look at it is that the device-specific aspects are handled by drivers, and hypervisor/architecture/system-specific aspects by the plugin. The problem is, that split may not always be as clear-cut | |
| 16:31:37 | Sundar_ | From a device vendor's POV, the split between plugins and drivers is a bit artificial - they have to split their work in two different modules | |
| 16:32:04 | Sundar_ | Have you had a chance to look at the Cyborg driver/agent API or the driver model? | |
| 16:32:24 | efried | I don't think so. I bet I have it queued up somewhere, but if you have the link at your fingertips...? | |
| 16:33:59 | Sundar_ | #link https://review.openstack.org/#/c/561849/ may help a bit. It is not an introductory doc, and we may need to update it further depending on our discusisons | |
| 16:36:15 | Sundar_ | AT this point, the drivers's role is mainly to handle discovery and enumeration of devices. I thought we will extend it to handle os-acc interaction. However, when you proposed a plugin, I thought that perhaps Power is too complicated to fit that, and that's why you want a plugin | |
| 16:37:05 | Sundar_ | However, based on your explanation of how Power works, it seems that the code has to invoke REST APIs for most device interactions, whether it resides in a plugin or a driver. | |
| 16:37:37 | Sundar_ | So, it seems to me that you do not lose any functionality or extensibility if Power code is encapsulated in a Cyborg driver | |
| 16:40:36 | Sundar_ | The os-acc spec, as it stands today, is really a compromise to get plugins and drivers in the same framework such that a developer could either (a) place most of the work in the plugin and just update Cyborg, or (b) delegate most of the work to Cyborg and its drivers | |
| 16:41:23 | Sundar_ | For x86 + SRIOV, I think we will do (b) | |
| 16:44:22 | Sundar_ | Anyways, if you need more time to reflect on this, that's fine. We could sync back later today or tomorrow morning | |
| 16:45:41 | Sundar_ | brb in 5 min | |
| 16:51:51 | Sundar_ | back | |
| 16:53:09 | efried | Sundar_: Digesting. | |
| 16:53:42 | efried | Sundar_: It may be a case of who's driving the bus. | |
| 16:54:12 | efried | Sundar_: When nova has the reins and needs to call out to make things happen, that goes through os-acc and the plugin framework. | |
| 16:54:56 | efried | Sundar_: But when cyborg itself is doing its setup, discovery, and maintenance, that goes through the driver. | |
| 16:55:32 | efried | Sundar_: For Power, both of those things will involve talking to the NovaLink REST API. | |
| 16:56:04 | Sundar_ | What if os-acc calls into Cyborg agent through published APIs, and that delegates to appropriate drivers? (Just questioning, not advocating) | |
| 16:57:21 | efried | Sundar_: I actually don't mind how (or even whether) it's split out as long as the appropriate level of control is available in the appropriate paths. | |
| 16:57:42 | efried | If we want a plugin and a driver to be the same thing, that's fine by me. | |
| 16:59:12 | efried | We just need to enumerate the operations we need and make sure that any that *need* to be platform-specific are part of the/an extensible interface. | |
| 16:59:50 | Sundar_ | Cool. Glad to see we are converging. I'll digest that and get back to you. What times are you available for a 30-min sync this eve or tomorrow morning? | |
| 17:00:09 | efried | Which involves some level of understanding of different platforms as you design it. For example, I gather it came as something of a surprise when you learned that you can't discover devices on a Power system by running lsdev or walking the /dev file system. | |
| 17:01:54 | efried | Sundar_: We can arrange a slot any time in the next 5h, or any time tomorrow. I will need to step away at some point, but I don't know when it will be (waiting for A/C guy to call me) so I need some way to get in touch with you if it's going to conflict with whatever we set up. I think I have your email address. | |
| 17:06:14 | efried | Sundar_: Ah, that call just came in. So I'll be afk for an hour or two, but we should be able to sync up after that. | |
| 17:23:31 | Sundar_ | Sounds good. I'll ping you later today. Thanks, efried. | |
| #openstack-cyborg - 2018-07-31 | |||
| 04:55:05 | openstackgerrit | Li Liu proposed openstack/cyborg master: Added rest API for FPGA programming https://review.openstack.org/579315 | |
| 08:21:22 | openstackgerrit | wangzhh proposed openstack/cyborg master: Imply new cyborg deployable api https://review.openstack.org/584641 | |
| 09:10:33 | openstackgerrit | JiangGuocai proposed openstack/cyborg master: Add HPTS driver, (HPTS: High Precision Time Synhronization cards) https://review.openstack.org/586994 | |
| 09:47:32 | openstackgerrit | JiangGuocai proposed openstack/cyborg master: Add HPTS driver, (HPTS: High Precision Time Synhronization cards) https://review.openstack.org/586994 | |
| 12:01:48 | openstackgerrit | JiangGuocai proposed openstack/cyborg master: Add HPTS driver, (HPTS: High Precision Time Synhronization cards) https://review.openstack.org/586994 | |
| 15:05:51 | openstackgerrit | wangzhh proposed openstack/python-cyborgclient master: Add filter to list https://review.openstack.org/586916 | |
| 15:35:30 | openstackgerrit | wangzhh proposed openstack/python-cyborgclient master: Add filter to list https://review.openstack.org/586916 | |
| #openstack-cyborg - 2018-08-01 | |||
| 14:06:18 | Li_Liu | #info Li_Liu | |
| 14:06:24 | Li_Liu | Hi guys | |
| 14:07:13 | Sundar | #info Sundar | |
| 14:07:17 | Sundar | Hi | |
| 14:07:24 | Li_Liu | Hey Sundar | |
| 14:07:49 | HongboZhao | Hi | |
| 14:08:38 | Li_Liu | Let's wait for couple minutes | |
| 14:08:51 | efried | ō/ | |
| 14:11:00 | openstack | Meeting started Wed Aug 1 14:11:00 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:11:00 | shaohe_feng | #startmeeting openstack-cyborg | |
| 14:11:02 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 14:11:04 | openstack | The meeting name has been set to 'openstack_cyborg' | |
| 14:11:22 | shaohe_feng | #topic Roll Call | |
| 14:11:32 | shaohe_feng | #info shaohe_feng | |
| 14:11:37 | Li_Liu | #info Li_Liu | |
| 14:11:42 | shaohe_feng | Sundar, morning | |
| 14:11:43 | Helloway_ | #info Helloway | |
| 14:12:25 | Sundar | Hi Shaohe | |
| 14:12:31 | Sundar | #info SUndar | |
| 14:13:30 | shaohe_feng | Li_Liu, what's the agenda of today's meeting? | |
| 14:13:34 | Li_Liu | #topic sub team status | |
| 14:14:06 | Li_Liu | I will go first for documentation team | |
| 14:14:15 | shaohe_feng | good. | |
| 14:14:29 | shaohe_feng | we missing so many docs | |
| 14:14:54 | Li_Liu | We had a kick off meeting earlier today to discuss what need to be done for R | |
| 14:15:21 | Li_Liu | #lind https://etherpad.openstack.org/p/rocky-cyborg-doc | |
| 14:15:25 | Li_Liu | #link https://etherpad.openstack.org/p/rocky-cyborg-doc | |
| 14:15:51 | Li_Liu | the meeting minutes can be found here | |
| 14:16:39 | Li_Liu | in case anyone want to add anything to the documentation list, feel free to edit the etherpad | |
| 14:16:45 | Li_Liu | that's from me | |
| 14:17:10 | shaohe_feng | Sundar, are you here? | |
| 14:17:22 | Li_Liu | shaohe_feng, you wanna do a quick summary on the driver sub team meeting? | |
| 14:17:38 | shaohe_feng | Ok. | |
| 14:17:48 | xinran__ | #info xinran__ | |
| 14:17:51 | xinran__ | Hi all | |
| 14:18:31 | shaohe_feng | xinran__, evening | |
| 14:18:40 | shaohe_feng | dolpher, evening | |
| 14:18:42 | Li_Liu | Hi xinran | |
| 14:18:53 | dolpher | hi | |
| 14:19:00 | shaohe_feng | we should refactor the drivers structure. | |
| 14:19:23 | shaohe_feng | Sundar and Coco will can help with this. | |
| 14:19:33 | Li_Liu | ok | |
| 14:19:34 | Sundar | Shaohe: can you expand on this? ^ | |
| 14:19:46 | shaohe_feng | Sundar, yes. | |
| 14:20:25 | shaohe_feng | Sundar, we had better unify the report info from different drivers | |
| 14:20:57 | Sundar | Do you mean the structures returned by GPU/FPGA drivers etc.? | |
| 14:21:23 | Li_Liu | ... | |
| 14:21:30 | Li_Liu | what was that | |
| 14:21:36 | shaohe_feng | what is sscout15? | |
| 14:22:03 | Li_Liu | I think he's just spamming... | |
| 14:22:30 | xinran__ | ads？ | |
| 14:23:25 | Li_Liu | my god... can we ban them? | |
| 14:23:25 | shaohe_feng | Sundar, for FPGA example, we should add function_uuid to the extra attribute | |
| 14:23:41 | Sundar | There must be some way to configure IRC servers for spam protection? | |
| 14:24:11 | efried | Yes, someone in charge can go to #openstack-infra request that +r be enabled for this channel. | |
| 14:24:27 | efried | That means only registered nicknames will be allowed to join. | |
| 14:24:36 | Li_Liu | ah, ok | |
| 14:24:50 | efried | Note that that's a double-edged sword, so use with caution. | |
| 14:25:06 | efried | I wouldn't think you expect a lot of casual users in this channel. | |
| 14:25:12 | efried | so it's probably appropriate here. | |
| 14:25:13 | Li_Liu | shaohe_feng, are you gonna extend the DB fields? or just use the attribute_list? | |
| 14:25:29 | Li_Liu | efried, sure, will look into it | |