Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2018-07-30
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 What I'd like to understand a bit more about, though, is what's a driver vs. a plugin?
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 Hi Sundar_.
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

Earlier   Later