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:32:33 * _gryf will not attend summit, unless he'll find a position in other company who will let him to do so :)
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
15:54:16 <jkilpatr> for some accelerators we need to start with 1-1 vm accelerator and wait for others to develop muxing
15:54:29 <jkilpatr> other things you can just go ahead and do it, for example most network acceleration doesn't care
15:54:30 <_gryf> every cyborg driver have to have knowledge how it may be attached to the vm
15:54:37 <_gryf> definitely
15:56:01 <_gryf> I guess network acceleration is the other type of acceleration, since we do not pass any accelerated functions to the VMs directly, but put such VM within accelerated networking functions, which neutron is handling
15:56:23 <jkilpatr> I think it's still under the scope of cyborg to make sure those functions are working
15:56:32 <jkilpatr> even if it's not a neutron thing
15:56:40 <jkilpatr> and won't that be a wonderful pattern breaker when it comes to driver design.
15:57:08 <crushil> I think we should end the meeting and we can keep talking about all this after the meeting?
15:57:44 <_gryf> I guess only zhipengh[m] can stop the meeting
15:57:52 <crushil> We can try
15:57:55 <_gryf> k
15:57:59 <_gryf> #endmeeting
15:58:05 <_gryf> ¯\(°_o)/¯
15:58:07 <crushil> lol
15:58:21 <jkilpatr> hope zhipengh[m] is ok
15:58:31 <crushil> Ya
15:58:31 <jkilpatr> anyawys matrix should cache this for him and he can comment when he's back online
15:58:39 <_gryf> right.
16:01:05 <_gryf> ok. thank you guys. Let me update my bp regarding crushil comments, and I'll jump into another round of review.
16:09:24 <zhipengh[m]> .... Network sucks today
16:09:34 <jkilpatr> welcome back!
16:10:02 <zhipengh[m]> I've been cut off from time to time
16:11:02 <zhipengh[m]> Let me go through the minutes later lol, thank you guys for keeping up the good work
16:11:14 <zhipengh[m]> Let me end the meeting first just in case ...
16:11:23 <zhipengh[m]> #endmeeting