| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-05-03 | |||
| 16:00:34 | goldenfri | yes, I'm going to work on it more today | |
| 16:00:41 | zhipeng | that way you could kickoff the deep dive discussion with SWG requirements | |
| 16:00:41 | goldenfri | I left the placeholder there | |
| 16:00:45 | zhipeng | :) nice | |
| 16:01:03 | zhipeng | and then Justin pick up and introduce the technical stuff | |
| 16:01:11 | jkilpatr | goldenfri, looking at your speaker notes. From what I understand you would spawn an instance then ping cyborg and say "attach a gpu to this instance" and cyborg takes care of the rest | |
| 16:01:21 | jkilpatr | right zhipeng? or are we using tags on instance creation? | |
| 16:01:35 | goldenfri | yea I wasn't sure about that | |
| 16:01:57 | zhipeng | I think so | |
| 16:01:58 | jkilpatr | the api design makes it look like the latter, but the nova interaction is fuzzy, if we attach the accelerator after the instance is spawned how do we make sure it's in the right spot? migration | |
| 16:02:22 | zhipeng | I think for the attach action | |
| 16:02:30 | zhipeng | user should not directly ping cyborg | |
| 16:02:35 | zhipeng | it should just use nova | |
| 16:02:40 | zhipeng | like how nova attach the volume | |
| 16:02:59 | zhipeng | that is why Roman mentioned that there are modifications needed in nova | |
| 16:03:02 | jkilpatr | ok so some special flavor or tag? that's fine Cyborg helps with scheduling and setup in the first place. | |
| 16:03:11 | zhipeng | yep | |
| 16:03:57 | zhipeng | so it would be like nova attach GPU instance-id, and it will call cyborg api | |
| 16:04:12 | goldenfri | so it would still need a tag to work with cyborg? | |
| 16:04:29 | jkilpatr | goldenfri, yes but cyborg would help handle other bits, like making sure the gpu is working, that it's not overloaded etc | |
| 16:04:33 | zhipeng | not a tag, but just a resource class I think | |
| 16:04:41 | zhipeng | like a tag | |
| 16:05:05 | jkilpatr | not to mention more thoughtful scheduling, don't fill up instances with accelerators until other computes are full | |
| 16:05:15 | goldenfri | right, that would be huge | |
| 16:05:22 | zhipeng | right | |
| 16:05:26 | goldenfri | like a priority | |
| 16:05:52 | jkilpatr | goldenfri, right now if you have more than one gpu in a machine how do you make sure they all get used? | |
| 16:05:55 | jkilpatr | you just don't? | |
| 16:06:18 | goldenfri | basically, you have to micromanage it | |
| 16:06:25 | jkilpatr | :( | |
| 16:06:39 | goldenfri | well it won't let you spawn if there are no GPUs available | |
| 16:07:19 | jkilpatr | I think cyborg will really shine when gpu virtualization matures | |
| 16:07:47 | jkilpatr | then load monitoring becomes more important because it's a timesliced not a monlithic asset, but getting ahead of ourselves. | |
| 16:07:56 | zhipeng | jkilpatr +1 | |
| 16:08:05 | goldenfri | I agree, there is also the issue of KVM tuning, cpu pinning etc | |
| 16:08:12 | goldenfri | I assume cyborg won't do any of that | |
| 16:08:23 | jkilpatr | goldenfri, why not, just make a driver for it | |
| 16:08:53 | goldenfri | That would be great | |
| 16:08:54 | jkilpatr | drivers just have attach/detach setup/uninstall commands, setup would just be a do nothing function, attach/detach would just pin to a cpu on the same NUMA as the gpu | |
| 16:08:56 | jkilpatr | that's what you want right? | |
| 16:09:13 | jkilpatr | then you would take the instance and tag it for gpu and gpu_pinning drivers and boom its done | |
| 16:09:13 | goldenfri | yea because if you don't do any tuning performance is pretty bad | |
| 16:09:56 | jkilpatr | goldenfri, or you could just include pinning in your gpu 'driver'. This is why I think the drivers are the most important parts of Nova, its just the playbooks/ tools we already make to handle this just standardized to integrate with a management framework (cyborg api) | |
| 16:10:16 | goldenfri | sounds good | |
| 16:11:33 | zhipeng | shall we combine the bio slides into one ? | |
| 16:11:51 | goldenfri | I think so | |
| 16:12:36 | jkilpatr | I don't care too much, but I like my Saturn V picture | |
| 16:12:51 | goldenfri | yea that is a pretty sweet picture | |
| 16:12:54 | zhipeng | haha i like that too | |
| 16:13:07 | zhipeng | Jim you should pick a pic as well | |
| 16:13:18 | goldenfri | yea I will | |
| 16:13:23 | zhipeng | we could shrink the pics to put them at the bottom of the page | |
| 16:13:28 | zhipeng | and sqeeze the text | |
| 16:14:01 | goldenfri | zhipeng where did you want the SWG intro slide? | |
| 16:14:49 | zhipeng | now it is page 10 | |
| 16:14:54 | zhipeng | i put the holder there | |
| 16:15:12 | goldenfri | oh wait I see it | |
| 16:16:33 | goldenfri | I'll add add something about using the gpu drivers for KVM turning later today, I think that is pretty compelling. | |
| 16:17:43 | jkilpatr | goldenfri, the point we're trying to get across is that cyborg drivers can be for anything you want to do to accelerate instances, if it means finding a non numa compute for your program that's great, write one. | |
| 16:18:13 | goldenfri | yea I think that is very important | |
| 16:18:26 | jkilpatr | by providing a framework that's good enough to work with arbitrary accelerators it has to be good enough to do basic tunings, so we may as well make them drivers too so they can take advantage of the management framework | |
| 16:18:40 | jkilpatr | at a high level cyborg is a scripting standard and scripting management engine. | |
| 16:20:52 | zhipeng | and in that thought, Cinder should be this way as well :P | |
| 16:21:03 | zhipeng | all the device mgmt modules should be designed this way | |
| 16:21:13 | goldenfri | :) | |
| 16:24:47 | jkilpatr | zhipeng, see how I slipped in the driver on slide 17 | |
| 16:25:11 | jkilpatr | the diagram as problems because if we draw enough lines to cover everything we have a blob not a slide. | |
| 16:25:28 | zhipeng | haha yes | |
| 16:55:25 | zhipeng | #endmeeting | |
| 16:55:27 | openstack | Meeting ended Wed May 3 16:55:25 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:55:29 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-05-03-15.02.html | |
| 16:55:30 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-05-03-15.02.txt | |
| 16:55:31 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-05-03-15.02.log.html | |
| 16:55:35 | zhipeng | almost forgot ... | |
| 17:08:40 | jkilpatr | good catch | |
| #openstack-cyborg - 2017-05-04 | |||
| 07:04:22 | _gryf | zhipengh[m], hi, yesterday was national holiday in Poland, hence my absence :) | |
| 07:57:12 | zhipengh[m] | Haha no problem :) | |
| 07:57:46 | zhipengh[m] | So it is about the may 3rd Constitution right ? | |
| 08:42:45 | _gryf | right :) | |
| #openstack-cyborg - 2017-05-10 | |||
| 14:50:19 | jkilpatr | morning everyone | |
| 14:50:39 | jkilpatr | if you're here for the meeting we're mostly busy with summit this week and probably won't be having one. | |
| 14:50:48 | jkilpatr | watch our presentation today when it's posted :) | |
| 14:51:17 | zhipengh[m] | Post the YouTube link here :p | |
| #openstack-cyborg - 2017-05-11 | |||
| 16:39:44 | ttk2[m] | https://www.youtube.com/watch?v=sEBSL2sbeZk | |
| 16:40:16 | ttk2[m] | so I think we should try and finish spec next week. crushil do you have time early next week to talk about cyborg/nova for a bit? | |
| 16:40:43 | ttk2[m] | I want to get into writing code, but I might be busy with other thins for a little while. | |
| 16:42:17 | crushil | ttk2[m], Sure | |
| 17:28:26 | zhipengh[m] | Let's have a spec sprint next Wed and hopefully settle them down :) | |
| #openstack-cyborg - 2017-05-12 | |||
| 17:14:39 | jkilpatr | random thought of the day, how in the world do you do CI for an accelerator project? just pull out bare metal? | |
| 17:15:20 | jkilpatr | also for implementations I think we should start from both ends (API/Driver) and meet in the middle with the agent and conductor | |
| 17:16:19 | gryf | there has to be at least one of the accelerators available for test | |
| 17:16:25 | gryf | so basically - yeah | |
| 17:16:30 | gryf | bare metal | |
| 17:16:56 | jkilpatr | I have baremetal Ci running now, but it's a pricey endevor. I guess we will have to have unit tests and mostly trust them. | |
| 17:19:37 | gryf | in neutorn or cinder they shift burden of the drivers testing to vendors | |
| 17:19:40 | gryf | afairc | |
| 17:20:37 | gryf | so that it is possible to jump with your own accelerator and driver, but you have to provide appropriate test env | |
| 17:29:26 | jkilpatr | gryf, might be most cost feasible to get a blade server with pci slots in the blades and just get hardware donations of accelerators. But that's far far in the future, implementation now | |
| 17:29:43 | jkilpatr | zhipengh[m], you're doing the api right? thoughts on starting that? I'll start the conductor at the same time so we can colab | |
| 17:29:58 | jkilpatr | who's got the dummy driver again? | |