Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2017-04-12
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
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 jkilpatr anyawys matrix should cache this for him and he can comment when he's back online
15:58:31 crushil Ya
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
16:11:24 openstack Meeting ended Wed Apr 12 16:11:23 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:11:26 openstack Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-04-12-15.07.html
16:11:27 openstack Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-04-12-15.07.txt
16:11:28 openstack Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-04-12-15.07.log.html
#openstack-cyborg - 2017-04-19
15:00:08 jkilpatr \0 hey everyone.
15:00:22 NokMikeR Evening
15:01:21 openstack Meeting started Wed Apr 19 15:01:21 2017 UTC and is due to finish in 60 minutes. The chair is zhipeng_. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:21 zhipeng_ #startmeeting openstack-cyborg

Earlier   Later