Wednesday, 2017-06-14

*** mikeH has quit IRC03:01
*** adreznec has quit IRC05:43
*** adreznec has joined #openstack-cyborg05:43
*** joseppc has joined #openstack-cyborg07:58
*** joseppc has joined #openstack-cyborg07:58
*** jkilpatr has quit IRC10:30
*** jkilpatr has joined #openstack-cyborg10:48
*** mikeH has joined #openstack-cyborg11:49
*** crushil has joined #openstack-cyborg13:50
jkilpatrsomehow oslo config is more complicated than messaging.14:35
*** zhipeng has joined #openstack-cyborg14:57
zhipenghi guys15:00
zhipeng#startmeeting openstack-cyborg15:01
openstackMeeting started Wed Jun 14 15:01:19 2017 UTC and is due to finish in 60 minutes.  The chair is zhipeng. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:01
openstackThe meeting name has been set to 'openstack_cyborg'15:01
zhipeng#topic BP discussion15:01
zhipeng#info the api spec has been updated to reflect the latest comment15:01
zhipengplz help review it, would be nice to merge it by the end of this week15:03
zhipengand then I think I will take over the cyborg-nova interaction spec15:04
zhipengany thoughts on the api spec so far ?15:06
crushilzhipeng, Will do15:06
crushilNeed to look at the API spec15:06
zhipengokey no problem15:06
zhipengmoving on to the next topic15:07
zhipeng#topic code development process15:07
zhipengcrushil how's the code going ?15:07
crushilIt's going. I have pushed the WIP up for the driver. I will fill out my code pending your work and jkilpatr's work15:08
jkilpatrmorning everyone.15:08
jkilpatrConductor is very stubby working on getting it hooked up to rabbit today.15:09
zhipengmorning :)15:09
zhipengcrushil have you submitted the code yet ?15:09
jkilpatryup he did on sudnay15:10
crushilMorning jkilpatr15:10
zhipengoh did not see that yet15:10
zhipengwell there is a thought when I update the api spec today15:11
jkilpatrI have a patch up for an internal accelerator object because I need one in both the conductor and the agent and didn't want to duplicate code.15:11
zhipengthat the generic driver should morph into a standalone library for local and remote accelerator attach/detach15:11
jkilpatrso that means we have attach/detach library and then the pci passthrough driver build ontop of it?15:12
zhipenglike os-brick15:12
jkilpatrok no idea what os-brick is15:12
zhipengyes, just import the lib and use it15:13
zhipengso the background story is15:13
zhipengback in the days15:13
zhipengevery cinder driver has to do attach/detach on its own15:13
zhipengeither iSCSI, FC, or what have you15:13
zhipengthen cinder project extract that part of code out and formed a new sub project called os-brick15:14
zhipengbascially provide a common lib for the attach/detach15:14
zhipengthe benefit is that, you could use it even Nova is not involved15:14
zhipengfor example attach a volume for baremetal host15:14
zhipengand cinder driver could just include the lib and call the functions they need15:15
crushilzhipeng, So, are you proposing we should move our generic driver code eventually into something like OS-brick?15:17
zhipengyes that is my current thinking15:17
zhipengin the near future15:18
crushilI don't understand why though?15:18
jkilpatrfor the sake of abstraction15:19
jkilpatrinstead of having to attach.nvidiagraphicsdriver15:19
zhipengcoz currently you are defining the basic operations for the drivers right ?15:19
jkilpatrwe would do attach(nvidiagraphics driver object)15:19
zhipengand at the end of the day, most of the attach/detach operstions will be the same for most of the drivers15:20
jkilpatrtoo much abstraction is counterproductive and I see that in a lot of openstack projects, but this level makes sense.15:20
crushilOk, we can talk more about it as the design progresses15:21
jkilpatrI find it easier to write somthing monolithic then I understand how to break it out easier15:21
zhipengyes of course :)15:22
zhipengenough of the microservice hype15:23
jkilpatrtech has a bad habit of coming up with ideas that are great in very specific situations then applying them to everything and realizing their bad ideas to follow blindly15:24
jkilpatrin general do what makes sense.15:24
jkilpatrAnyways back on topic. RPC vs messaging vs direct linking15:25
jkilpatrrpc places the responsibility for error handling into the caller, so for example if I where to have the conductor call attach via rpc then the conductor would need to handle possible errors (at least the way I understand it)15:25
jkilpatrin general I think API -> conductor should be RPC15:26
jkilpatrand conductor -> agents should be message passing15:26
jkilpatrand then agents -> drivers should be just direct linking (we import the python modules on the same machine)15:26
zhipengi think it makes sense on the agent->driver side15:27
jkilpatradding a messaging/rpc server to every driver is just bad design, what if you load 100 drivers? do you just have 100 new servers that need to run and listen15:27
zhipengbut considering scaling problem, conductor should still rpc to agent ?15:27
jkilpatrso rpc would be less messaging load sure, but then what if the command fails, we have to put the error handling into the conductor15:29
jkilpatrwhere I'd argue it really does not belong15:29
jkilpatrI guess we could have a wrapper to handle all failures on the agent. but I'm still not super happy with the idea.15:30
jkilpatropinions on this are appreciated.15:30
zhipengas far as I know, when we deploy cyborg, conductor is more than likely on a different node than the agent15:31
zhipengso even taking into consideration of the error handling15:31
zhipengRPC would still be a preferred choice15:31
jkilpatrok then.15:51
jkilpatrI still need to figure out how oslodb works so that the conductor can save stuff out.15:52
zhipengright :)15:53
jkilpatrso we should probably define when we want to merge these components, do we want to go all the way to first POC with everything in reviews?15:55
zhipengi think i could try15:56
jkilpatrit's going to make all up tests a little frustrating (trying to get all the components together) but I'm fine with that.15:57
zhipengwell we definitely will be expecting failures :P15:59
zhipengfor sure15:59
*** joseppc has quit IRC16:22
*** zhipeng has quit IRC16:58
*** goldenfri has joined #openstack-cyborg18:02
*** crushil has quit IRC19:37
*** crushil has joined #openstack-cyborg19:47
*** goldenfri has quit IRC19:52
*** goldenfr_ has joined #openstack-cyborg20:10
*** jkilpatr has quit IRC21:11
*** mikeH has quit IRC21:57
*** jkilpatr has joined #openstack-cyborg21:58

Generated by 2.15.3 by Marius Gedminas - find it at!