Wednesday, 2017-05-03

*** joseppc has joined #openstack-cyborg07:29
*** joseppc has joined #openstack-cyborg07:29
*** joseppc has quit IRC08:15
*** adreznec has quit IRC09:30
*** adreznec has joined #openstack-cyborg09:31
*** jkilpatr has quit IRC10:31
*** jkilpatr has joined #openstack-cyborg10:49
*** mikeH_ has joined #openstack-cyborg11:43
*** mpaolino has joined #openstack-cyborg13:03
*** zhipeng has joined #openstack-cyborg13:49
*** crushil has joined #openstack-cyborg13:52
jkilpatr\o14:57
zhipenghey14:59
goldenfrihello14:59
crushil\o15:00
zhipeng#startmeeting openstack-cyborg15:02
openstackMeeting started Wed May  3 15:02:23 2017 UTC and is due to finish in 60 minutes.  The chair is zhipeng. Information about MeetBot at http://wiki.debian.org/MeetBot.15:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:02
openstackThe meeting name has been set to 'openstack_cyborg'15:02
zhipeng#topic BP discussion15:03
zhipenglet's get a quick review of the spec work15:03
zhipengany outstanding issues ?15:03
jkilpatrwaiting for Roman to get back to me on my last patchset, he commented he had one comment on patchset 4 left but I think I addressed all of them so   ¯\_(ツ)_/¯15:04
jkilpatrooh there's a new driver patch, let me look at it.15:04
zhipenghaha i also notice that one15:05
zhipengping _gryf15:05
zhipengcrushil anything from your side ?15:07
crushilNope. Just updated the patch like an hour ago. Nothing else. Will look at the summit presentation that you sent this morning15:08
jkilpatrcrushil, look at my slide on drivers, if our visions diverge we need to hash that out. Looking at your latest patch I'm not quite sure.15:10
crushiljkilpatr, Will do15:12
crushiljkilpatr, In any case, can you still review the latest patch?15:15
jkilpatralready did15:15
jkilpatrwell I left one comment.15:15
crushilI will try to come back sooner with the next patchset. I was busy with downstream things for the past month. Should have more time this month, hopefully15:16
jkilpatrwhat outstanding as far as reviews go15:22
jkilpatrI think everyone's happy with the agent, speak now or forever hold your -215:23
jkilpatrI'm happy with the api patch so +115:23
jkilpatrcyborg/nova needs bullet points, too wordy right now.15:25
zhipengagree jkilpatr on the agent15:39
zhipengand i think driver's spec after some fixing from crushil15:39
zhipengshould be ok to merge as well15:39
zhipengthe api spec will need further polishing I guess15:49
zhipengsince ClintD also review ed that ....15:49
zhipengokey let's move to the next topic15:50
zhipeng#topic BoS slide prep15:50
zhipengping jkilpatr goldenfri15:50
zhipenglet's discuss the flow15:50
jkilpatrzhipeng, so the flow I'm getting right now is  we introduce ourselves, talk a little about cyborg as a cool project for Telecom/NFV, then we get into talking about why everyone needs and can use accelerators, and how cyborg will make that usecase easy for everyone, original stakeholders included15:51
jkilpatrare slides 7 and 8 redundant? and maybe we want to move 6 somewhere after 7 once we go from "hey nomand was a project for nfv hardware" to "cyborg is for everyone"15:52
*** mpaolino has quit IRC15:53
zhipeng6 is like a starter for the conversation15:53
zhipengthat acceleration is a requirement, no longer just an icing on the top15:53
zhipengand 7 and 8 provides the history15:54
zhipengbut I guess I should merge these two into one15:54
zhipeng7 and 815:54
jkilpatrdo we want to move goldenfri's stuff forward? not sure it makes sense at the back?15:54
goldenfriso I've pinged Blair for some information on GPU requirements because I haven't heard anything recently15:55
goldenfriso I added a slide on GPU15:55
goldenfribut yea I don't think it should go there15:55
jkilpatrok so, intro, history, why nfv and gpgpu sucks on openstack right now, why everyone needs accelerators, cyborg and it's design15:55
goldenfrimakes sense15:56
jkilpatrthat would put goldenfri's stuff somehwere around the background slides15:56
jkilpatrgoldenfri, go ahead and drop it where you think it makes the most sense right now.15:56
zhipengmaybe 18 should be after 10 ?15:57
zhipengyes, so what I imagined is that 10 - 12 provides the motivation within the OpenStack15:58
zhipengBackground parts covers high level descriptions, identify the need in a broader sense15:59
jkilpatrthen we drill down into the details, sounds great.15:59
zhipengyes15:59
goldenfriah ok, I've moved it in there before the "why cyborg"15:59
zhipengyes that looks good15:59
zhipenggoldenfri could you add another slide of intro on the SWG ?16:00
goldenfriyes, I'm going to work on it more today16:00
zhipengthat way you could kickoff the deep dive discussion with SWG requirements16:00
goldenfriI left the placeholder there16:00
zhipeng:) nice16:00
zhipengand then Justin pick up and introduce the technical stuff16:01
jkilpatrgoldenfri, 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 rest16:01
jkilpatrright zhipeng? or are we using tags on instance creation?16:01
goldenfriyea I wasn't sure about that16:01
zhipengI think so16:01
jkilpatrthe 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? migration16:01
zhipengI think for the attach action16:02
zhipenguser should not directly ping cyborg16:02
zhipengit should just use nova16:02
zhipenglike how nova attach the volume16:02
zhipengthat is why Roman mentioned that there are modifications needed in nova16:02
jkilpatrok so some special flavor or tag? that's fine Cyborg helps with scheduling and setup in the first place.16:03
zhipengyep16:03
zhipengso it would be like nova attach GPU instance-id, and it will call cyborg api16:03
goldenfriso it would still need a tag to work with cyborg?16:04
jkilpatrgoldenfri, yes but cyborg would help handle other bits, like making sure the gpu is working, that it's not overloaded etc16:04
zhipengnot a tag, but just a resource class I think16:04
zhipenglike a tag16:04
jkilpatrnot to mention more thoughtful scheduling, don't fill up instances with accelerators until other computes are full16:05
goldenfriright, that would be huge16:05
zhipengright16:05
goldenfrilike a priority16:05
jkilpatrgoldenfri, right now if you have more than one gpu in a machine how do you make sure they all get used?16:05
jkilpatryou just don't?16:05
goldenfribasically, you have to micromanage it16:06
jkilpatr:(16:06
goldenfriwell it won't let you spawn if there are no GPUs available16:06
jkilpatrI think cyborg will really shine when gpu virtualization matures16:07
jkilpatrthen load monitoring becomes more important because it's a timesliced not a monlithic asset, but getting ahead of ourselves.16:07
zhipengjkilpatr +116:07
goldenfriI agree, there is also the issue of KVM tuning, cpu pinning etc16:08
goldenfriI assume cyborg won't do any of that16:08
jkilpatrgoldenfri, why not, just make a driver for it16:08
goldenfriThat would be great16:08
jkilpatrdrivers 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 gpu16:08
jkilpatrthat's what you want right?16:08
jkilpatrthen you would take the instance and tag it for gpu and gpu_pinning drivers and boom its done16:09
goldenfriyea because if you don't do any tuning performance is pretty bad16:09
jkilpatrgoldenfri, 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:09
goldenfrisounds good16:10
zhipengshall we combine the bio slides into one ?16:11
goldenfriI think so16:11
jkilpatrI don't care too much, but I like my Saturn V picture16:12
goldenfriyea that is a pretty sweet picture16:12
zhipenghaha i like that too16:12
zhipengJim you should pick a pic as well16:13
goldenfriyea I will16:13
zhipengwe could shrink the pics to put them at the bottom of the page16:13
zhipengand sqeeze the text16:13
goldenfrizhipeng where did you want the SWG intro slide?16:14
zhipengnow it is page 1016:14
zhipengi put the holder there16:14
goldenfrioh wait I see it16:15
goldenfriI'll add add something about using the gpu drivers for KVM turning later today, I think that is pretty compelling.16:16
jkilpatrgoldenfri, 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:17
goldenfriyea I think that is very important16:18
jkilpatrby 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 framework16:18
jkilpatrat a high level cyborg is a scripting standard and scripting management engine.16:18
zhipengand in that thought, Cinder should be this way as well :P16:20
zhipengall the device mgmt modules should be designed this way16:21
goldenfri:)16:21
jkilpatrzhipeng, see how I slipped in the driver on slide 1716:24
jkilpatrthe diagram as problems because if we draw enough lines to cover everything we have a blob not a slide.16:25
zhipenghaha yes16:25
zhipeng#endmeeting16:55
openstackMeeting ended Wed May  3 16:55:25 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:55
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-05-03-15.02.html16:55
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-05-03-15.02.txt16:55
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-05-03-15.02.log.html16:55
zhipengalmost forgot ...16:55
*** mikeH_ has quit IRC16:55
*** zhipeng has quit IRC16:56
*** mikeH_ has joined #openstack-cyborg16:58
jkilpatrgood catch17:08
-openstackstatus- NOTICE: Gerrit on review.openstack.org is being restarted to accomodate a memory leak in Gerrit. Service should return shortly.18:52
*** crushil has quit IRC19:39
*** crushil has joined #openstack-cyborg19:53
*** jkilpatr has quit IRC22:05
*** jkilpatr has joined #openstack-cyborg22:39

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!