| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-04-05 | |||
| 15:43:04 | jkilpatr | I think that's fine for now. Maybe add some notifications to the operator that things need to be setup. | |
| 15:43:14 | jkilpatr | I think we could detect new accelerators without root | |
| 15:43:39 | zhipeng_ | yes that is ture | |
| 15:43:43 | zhipeng_ | true ... | |
| 15:43:49 | zhipeng_ | fat fingers | |
| 15:44:00 | zhipeng_ | #topic AoB | |
| 15:44:09 | zhipeng_ | okey any other buisness or topics | |
| 15:46:13 | crushil | Not from me | |
| 15:48:40 | jkilpatr | not from me either | |
| 15:48:45 | zhipeng_ | okey thank you guys for the great work on the bp patches, let's conclude the meeting earlier today :) | |
| 15:48:53 | zhipeng_ | see you guys on gerrit :P | |
| 15:48:58 | zhipeng_ | #endmeeting | |
| 15:49:00 | openstack | Meeting ended Wed Apr 5 15:48:58 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 15:49:01 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-04-05-15.03.html | |
| 15:49:02 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-04-05-15.03.txt | |
| 15:49:04 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-04-05-15.03.log.html | |
| #openstack-cyborg - 2017-04-12 | |||
| 14:01:46 | ewchan | Hi. This is Eugene Chan from Huawei. I would like to be an observer of the meeting today. | |
| 14:02:29 | zhipeng | cool :) | |
| 14:02:37 | NokMikeR | HI Eugene, welcome. | |
| 14:02:39 | zhipeng | our meeting will start one hour later | |
| 14:02:45 | zhipeng | but we could always chat :P | |
| 14:04:34 | ewchan | oh. thanks. it must be the dst changes. as it listed as 10am est in the cyborg site. | |
| 14:05:10 | zhipeng | i forgot to change lol | |
| 14:05:19 | zhipeng | thx for reminding | |
| 14:05:43 | ewchan | no problem :) | |
| 14:06:00 | NokMikeR | was the meeting normally held at 15:00 UTC? | |
| 14:06:29 | zhipeng | NokMikeR yes I think at least for the Pike cycle | |
| 15:01:29 | crushil | \o | |
| 15:06:50 | zhipengh[m] | Hey guys | |
| 15:07:04 | zhipengh[m] | My home network is very unstable | |
| 15:07:26 | zhipengh[m] | #startmeeting openstack-cyborg | |
| 15:07:27 | openstack | Meeting started Wed Apr 12 15:07:26 2017 UTC and is due to finish in 60 minutes. The chair is zhipengh[m]. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 15:07:28 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 15:07:31 | openstack | The meeting name has been set to 'openstack_cyborg' | |
| 15:07:53 | zhipengh[m] | #topic BP outstanding issues | |
| 15:16:02 | _gryf | I think we lost zhipengh[m] | |
| 15:16:19 | crushil | _gryf, I think so too | |
| 15:16:22 | jkilpatr | so I updated my review https://review.openstack.org/#/c/446091/ Id appreciate if someone could look at it | |
| 15:16:30 | _gryf | jkilpatr, will do. | |
| 15:16:36 | crushil | jkilpatr, I will too | |
| 15:17:11 | jkilpatr | has anyone else done another patchset I should look at? | |
| 15:17:14 | crushil | jkilpatr, Can you please remove the WIP from the commit message and give it a proper commit message? | |
| 15:17:25 | jkilpatr | oh sure that's easy. | |
| 15:17:52 | _gryf | my bp still needs some attention. esp in context of its correctness | |
| 15:18:06 | jkilpatr | _gryf, link? | |
| 15:18:20 | crushil | jkilpatr, _gryf Can you look at https://review.openstack.org/#/c/447257/ please? | |
| 15:18:21 | _gryf | #link https://review.openstack.org/#/q/project:openstack/cyborg | |
| 15:18:33 | _gryf | all cyborg work ^^ | |
| 15:18:44 | _gryf | #link https://review.openstack.org/#/c/448228/ | |
| 15:18:50 | _gryf | and that's mine ^^ | |
| 15:19:28 | _gryf | crushil, yup, I'll have it on my queue | |
| 15:19:33 | crushil | _gryf, I already gave it a first look | |
| 15:19:50 | _gryf | crushil, yes, I appreciate it :) | |
| 15:19:54 | crushil | _gryf, Can you address those comments? | |
| 15:20:03 | _gryf | I will. | |
| 15:20:06 | crushil | _gryf, Thanks | |
| 15:20:17 | _gryf | I just have limited time for doing this | |
| 15:20:33 | jkilpatr | so for the time being we are going to direct passthrough attachment of hardware? | |
| 15:20:45 | _gryf | since my division have different goals now, so that I have to do it at my free time | |
| 15:20:47 | jkilpatr | I don't think there are any other options that we can implement for a first release. | |
| 15:21:19 | _gryf | jkilpatr, that should be easy | |
| 15:22:24 | _gryf | maybe that was already discussed, and I didn't grasp it - does cyborg supposed to spin VMs? | |
| 15:24:14 | jkilpatr | from what I understand no | |
| 15:24:29 | jkilpatr | from what I understand we can't touch the VM's at all without seriously screwing with Nova we have to let nova do everything | |
| 15:24:41 | jkilpatr | meaning schedule, spin up, and maybe call out to us to attach if it allows. | |
| 15:25:06 | _gryf | that what I thought, hence my questions on your BP (cyborg conductor/agent) | |
| 15:26:38 | _gryf | I wasn't on PTG, that's why I'm wondering if there was some architectural decisions made regarding interaction between cyborg and rest of openstack services | |
| 15:26:58 | jkilpatr | _gryf, now that I know of, we should probably actually ask the nova team about this | |
| 15:27:21 | jkilpatr | get clear outlines for what we can and can't do, because I've got nothing but hearsay | |
| 15:27:26 | _gryf | certainly | |
| 15:28:13 | _gryf | I guess, that we can at least build a prototype with minimal changes in Nova, just to sell the idea | |
| 15:29:17 | _gryf | also communicate with nova team about that using irc/mailing list might be helpful | |
| 15:29:49 | _gryf | maybe reserving a slot for that on upcoming summit would be good (if possible, since it is not ptg) | |
| 15:31:32 | jkilpatr | I may or may not be there I haven't gotten final word yet. I didn't get a talk in :( | |
| 15:34:10 | jkilpatr | there's been some chatter about the placement API, we need look into that. | |
| 15:37:09 | _gryf | yes there is. currently it is qualitative aspect discussed (implementation already has started) | |
| 15:37:24 | _gryf | and also nested resource providers is the next topic | |
| 15:38:41 | _gryf | especially the last feature might be really interesting for us in context of exposing VF from accelerators (I assume that GPU also using virtual functions for virtualization) | |
| 15:39:26 | jkilpatr | so nova will have an api to support virtual functions? | |
| 15:40:28 | jkilpatr | also zhipengh[m] is less than 1 light minute away, looks like Saturn will know about his messages before we do. | |
| 15:40:40 | crushil | lol | |
| 15:40:48 | jkilpatr | fun fact Saturn is just over 1 light hour away. | |
| 15:41:00 | _gryf | ヽ（´ー｀） | |
| 15:42:13 | _gryf | jkilpatr, not sure about pci subsystem, but AFAIK plan was to completely map old resource handling with placement API som my cautious guess is yes | |
| 15:42:33 | _gryf | *about pci subsystem plans* | |
| 15:44:09 | jkilpatr | might work with some things, but I get the feeling a lot of work would be required to make drivers compatible with that sort of thing, like manufacturer side work. | |
| 15:46:02 | _gryf | jkilpatr, in which context? | |
| 15:46:28 | _gryf | like, in exposing right part of the virtualized (or not) subsystem to the vm via libvirt/xen/whatever? | |
| 15:47:09 | _gryf | since in the end we have to have a way to make VM to utilize accelerator | |
| 15:47:46 | _gryf | passing pci device is the simplest way, but its implementation in Nova is quite horrible | |
| 15:47:59 | jkilpatr | _gryf, ok maybe I'm confused are we talking about an api for direct pci attachment or an api to mux multiple vm's to a single physical resource | |
| 15:48:23 | _gryf | i guess both | |
| 15:48:25 | _gryf | like | |
| 15:48:58 | _gryf | some accelerators might be consumed only by one vm, since the amount of accelerated functions is… one | |
| 15:49:35 | _gryf | in that case one of the possible way for attachment to the VM is through PCI | |
| 15:50:18 | _gryf | or sort of SR-IOV-like, which basically are the same as PCI passthrough | |
| 15:51:19 | _gryf | otoh, we can have an accelerator which provides several VF (or some other way, like exposing devices on /dev filesystem) | |
| 15:51:43 | _gryf | so there would be many-to-many relation between accelerators and VMs | |
| 15:52:57 | _gryf | what I was talking about was a way to directly attach some accelerated function (using pci pass, vf pass, device pass) to the hypervisor | |
| 15:53:45 | _gryf | on top of that we can start building "drivers" for cyborg | |