| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-07-30 | |||
| 14:41:26 | shaohe_feng | edleafe, ok, thanks. | |
| 14:42:04 | shaohe_feng | Sundar, have talked with efried on nova interaction? | |
| 14:42:44 | Sundar | shaohe: the entire os-acc spec discussion is an extended conversation with efried :) | |
| 14:43:05 | shaohe_feng | these days we are so busy, sorry for the delay. | |
| 14:44:28 | shaohe_feng | but any one wants to learn more about how placement work during the cyborg/nova interaction. can discuss with xinran__ | |
| 14:44:54 | Sundar | shaohe: NP. | |
| 14:45:01 | Sundar | efried: Saw your reply in the spec. I can explain the Cyborg driver model. Would you be available at 9 am PDT? | |
| 14:45:02 | LI_Liu | I have to drop guys. Have a good night/day | |
| 14:45:26 | shaohe_feng | LI_Liu, have a good day. Bye. | |
| 14:45:35 | wangzhh | Bye, Uncle li. | |
| 14:45:49 | efried | Sundar: I.e. 1:15 from now? Yes, wfm. | |
| 14:46:22 | shaohe_feng | Coco, you miss the refacor of driver return data. Sundar suggested to use his VANs model. You can discuss it with him about more details. | |
| 14:46:28 | jiangguocai | shaohe_feng: for driver to call？can you take a simple for us, thanks | |
| 14:46:56 | shaohe_feng | jiangguocai, yes. will come out soon. | |
| 14:47:03 | Sundar | Great, efried. I'll catch you on #openstack-nova | |
| 14:47:15 | efried | Sundar: Here is probably more appropriate. | |
| 14:47:28 | efried | unless it will interrupt something else. | |
| 14:47:38 | xinran__ | wangzhh: you mean how cyborg report the resource to placement? | |
| 14:47:48 | shaohe_feng | jiangguocai, can you discribe your drivers? Let me give you a solution. | |
| 14:47:50 | shaohe_feng | here. | |
| 14:48:03 | Coco | OK, I will talk with Sundar about more details of the VANs model. | |
| 14:48:49 | wangzhh | xinran__, Yes. I want to know the data structure and how we call it. | |
| 14:49:40 | shaohe_feng | welcome jiapei | |
| 14:50:19 | jiapei | hey, morning Shaohe | |
| 14:50:33 | shaohe_feng | wangzhh, do you just pass the physical GPU to VM? | |
| 14:50:44 | shaohe_feng | nvdia? | |
| 14:50:47 | wangzhh | Yes。 | |
| 14:51:38 | shaohe_feng | One card is one GPU? | |
| 14:52:06 | wangzhh | Yes. No share mode now. | |
| 14:52:21 | xinran__ | wangzhh: you can check the provider_report in resource_tracker.py | |
| 14:54:32 | xinran__ | wangzhh: oh sorry these code is not in this patch | |
| 14:54:56 | xinran__ | wangzhh: let me check and tell you after meeting | |
| 14:55:06 | shaohe_feng | wangzhh, that's a not a complex use case. | |
| 14:55:09 | wangzhh | OK. | |
| 14:55:22 | shaohe_feng | next topic: | |
| 14:56:02 | shaohe_feng | #topic Traits and attribution format. | |
| 14:57:08 | shaohe_feng | maybe Coco and Sundar should pay a attention on this . | |
| 14:57:40 | Sundar | I need to drop off in 3 min. What is this topic about? | |
| 14:57:55 | shaohe_feng | if we want to the cyborg pick up the expect accelerators | |
| 14:58:24 | shaohe_feng | we should have enough info in the attribution of deployable . | |
| 14:59:06 | shaohe_feng | and driver return dates should report them. | |
| 14:59:40 | shaohe_feng | so we should add a new fields for the return VANs model? | |
| 15:00:46 | shaohe_feng | and if we want to scheduler pick up the right host. we should also report the correct traits. | |
| 15:00:59 | Sundar | Not sure I follow. The Cyborg drivers return enough data for the agent to create traits and RPs for that device | |
| 15:01:15 | shaohe_feng | Sundar, yes. | |
| 15:01:22 | Sundar | Anyways, I'll catch up on this. Please start an email thread on this | |
| 15:01:26 | xinran__ | wangzhh: device name, rc, trait, total number, these should be passed to placement by calling placement client | |
| 15:01:45 | Sundar | Bye for now. | |
| 15:01:51 | shaohe_feng | So who will report these infos? | |
| 15:02:55 | jiangguocai | shaohe_feng: Ok，I pushed hpts driver tonight，with review 587994. I need to add 'Custom_accelelerator_hpts' and Tairst，acc resource number to novi， can you give me some suggest. | |
| 15:02:56 | wangzhh | OK, xinran__, when will you commit the patch about it? | |
| 15:03:39 | xinran__ | Tmr morning | |
| 15:04:22 | wangzhh | Good! Thx. | |
| 15:04:31 | shaohe_feng | So let's please make our own tasks go well. | |
| 15:04:33 | xinran__ | :) | |
| 15:04:54 | shaohe_feng | #topic AoB | |
| 15:05:10 | shaohe_feng | ^ jiangguocai, wangzhh, Coco | |
| 15:05:28 | Coco | shaohe_feng, ? | |
| 15:05:54 | shaohe_feng | any things else want to talk? | |
| 15:06:15 | wangzhh | Nothing. | |
| 15:06:29 | shaohe_feng | OK, if no let's end the meeting. | |
| 15:06:39 | shaohe_feng | have a good night, every one. | |
| 15:06:42 | shaohe_feng | Bye. | |
| 15:06:46 | wangzhh | Bye, everyone. | |
| 15:06:59 | shaohe_feng | #endmeeting | |
| 15:07:02 | openstack | Meeting ended Mon Jul 30 15:06:59 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 15:07:03 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg_driver/2018/openstack_cyborg_driver.2018-07-30-14.00.html | |
| 15:07:04 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg_driver/2018/openstack_cyborg_driver.2018-07-30-14.00.txt | |
| 15:07:05 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg_driver/2018/openstack_cyborg_driver.2018-07-30-14.00.log.html | |
| 16:25:15 | Sundar_ | Hello | |
| 16:25:41 | efried | Hi Sundar_. | |
| 16:25:41 | efried | Seems like we've come to an agreement on most of the high points in the spec. If we just fix those up, I'll be happy with it. As I've said, I think a lot of the details will shake out in the implementation. | |
| 16:25:41 | efried | What I'd like to understand a bit more about, though, is what's a driver vs. a plugin? | |
| 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? | |