| *** mikeH has quit IRC | 03:01 | |
| *** adreznec has quit IRC | 05:43 | |
| *** adreznec has joined #openstack-cyborg | 05:43 | |
| *** joseppc has joined #openstack-cyborg | 07:58 | |
| *** joseppc has joined #openstack-cyborg | 07:58 | |
| *** jkilpatr has quit IRC | 10:30 | |
| *** jkilpatr has joined #openstack-cyborg | 10:48 | |
| *** mikeH has joined #openstack-cyborg | 11:49 | |
| *** crushil has joined #openstack-cyborg | 13:50 | |
| jkilpatr | somehow oslo config is more complicated than messaging. | 14:35 |
|---|---|---|
| *** zhipeng has joined #openstack-cyborg | 14:57 | |
| crushil | \o | 14:59 |
| zhipeng | hi guys | 15:00 |
| zhipeng | #startmeeting openstack-cyborg | 15:01 |
| openstack | Meeting 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 http://wiki.debian.org/MeetBot. | 15:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| openstack | The meeting name has been set to 'openstack_cyborg' | 15:01 |
| zhipeng | #topic BP discussion | 15:01 |
| zhipeng | #info the api spec has been updated to reflect the latest comment | 15:01 |
| zhipeng | #link https://review.openstack.org/#/c/445814/ | 15:02 |
| zhipeng | plz help review it, would be nice to merge it by the end of this week | 15:03 |
| zhipeng | and then I think I will take over the cyborg-nova interaction spec | 15:04 |
| zhipeng | any thoughts on the api spec so far ? | 15:06 |
| crushil | zhipeng, Will do | 15:06 |
| crushil | Need to look at the API spec | 15:06 |
| zhipeng | okey no problem | 15:06 |
| zhipeng | moving on to the next topic | 15:07 |
| zhipeng | #topic code development process | 15:07 |
| zhipeng | crushil how's the code going ? | 15:07 |
| crushil | It's going. I have pushed the WIP up for the driver. I will fill out my code pending your work and jkilpatr's work | 15:08 |
| jkilpatr | morning everyone. | 15:08 |
| jkilpatr | Conductor is very stubby working on getting it hooked up to rabbit today. | 15:09 |
| zhipeng | morning :) | 15:09 |
| zhipeng | crushil have you submitted the code yet ? | 15:09 |
| jkilpatr | yup he did on sudnay | 15:10 |
| jkilpatr | sunday* | 15:10 |
| crushil | Yup | 15:10 |
| crushil | Morning jkilpatr | 15:10 |
| zhipeng | oh did not see that yet | 15:10 |
| zhipeng | well there is a thought when I update the api spec today | 15:11 |
| jkilpatr | I 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 |
| zhipeng | that the generic driver should morph into a standalone library for local and remote accelerator attach/detach | 15:11 |
| jkilpatr | so that means we have attach/detach library and then the pci passthrough driver build ontop of it? | 15:12 |
| zhipeng | like os-brick | 15:12 |
| jkilpatr | ok no idea what os-brick is | 15:12 |
| zhipeng | yes, just import the lib and use it | 15:13 |
| zhipeng | so the background story is | 15:13 |
| zhipeng | back in the days | 15:13 |
| zhipeng | every cinder driver has to do attach/detach on its own | 15:13 |
| zhipeng | either iSCSI, FC, or what have you | 15:13 |
| zhipeng | then cinder project extract that part of code out and formed a new sub project called os-brick | 15:14 |
| zhipeng | bascially provide a common lib for the attach/detach | 15:14 |
| zhipeng | the benefit is that, you could use it even Nova is not involved | 15:14 |
| zhipeng | for example attach a volume for baremetal host | 15:14 |
| zhipeng | and cinder driver could just include the lib and call the functions they need | 15:15 |
| crushil | zhipeng, So, are you proposing we should move our generic driver code eventually into something like OS-brick? | 15:17 |
| zhipeng | yes that is my current thinking | 15:17 |
| zhipeng | in the near future | 15:18 |
| crushil | I don't understand why though? | 15:18 |
| jkilpatr | for the sake of abstraction | 15:19 |
| jkilpatr | instead of having to attach.nvidiagraphicsdriver | 15:19 |
| zhipeng | coz currently you are defining the basic operations for the drivers right ? | 15:19 |
| jkilpatr | we would do attach(nvidiagraphics driver object) | 15:19 |
| zhipeng | and at the end of the day, most of the attach/detach operstions will be the same for most of the drivers | 15:20 |
| zhipeng | yep | 15:20 |
| jkilpatr | too much abstraction is counterproductive and I see that in a lot of openstack projects, but this level makes sense. | 15:20 |
| crushil | Ok, we can talk more about it as the design progresses | 15:21 |
| jkilpatr | I find it easier to write somthing monolithic then I understand how to break it out easier | 15:21 |
| zhipeng | yes of course :) | 15:22 |
| zhipeng | haha | 15:22 |
| zhipeng | enough of the microservice hype | 15:23 |
| jkilpatr | tech 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 blindly | 15:24 |
| jkilpatr | in general do what makes sense. | 15:24 |
| jkilpatr | Anyways back on topic. RPC vs messaging vs direct linking | 15:25 |
| zhipeng | indeed | 15:25 |
| jkilpatr | rpc 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 |
| jkilpatr | in general I think API -> conductor should be RPC | 15:26 |
| jkilpatr | and conductor -> agents should be message passing | 15:26 |
| jkilpatr | and then agents -> drivers should be just direct linking (we import the python modules on the same machine) | 15:26 |
| zhipeng | i think it makes sense on the agent->driver side | 15:27 |
| jkilpatr | adding 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 listen | 15:27 |
| zhipeng | but considering scaling problem, conductor should still rpc to agent ? | 15:27 |
| jkilpatr | so rpc would be less messaging load sure, but then what if the command fails, we have to put the error handling into the conductor | 15:29 |
| jkilpatr | where I'd argue it really does not belong | 15:29 |
| jkilpatr | I 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 |
| jkilpatr | opinions on this are appreciated. | 15:30 |
| zhipeng | as far as I know, when we deploy cyborg, conductor is more than likely on a different node than the agent | 15:31 |
| zhipeng | so even taking into consideration of the error handling | 15:31 |
| zhipeng | RPC would still be a preferred choice | 15:31 |
| jkilpatr | ok then. | 15:51 |
| jkilpatr | I still need to figure out how oslodb works so that the conductor can save stuff out. | 15:52 |
| zhipeng | right :) | 15:53 |
| jkilpatr | so 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 |
| zhipeng | i think i could try | 15:56 |
| jkilpatr | it'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 |
| zhipeng | well we definitely will be expecting failures :P | 15:59 |
| zhipeng | for sure | 15:59 |
| *** joseppc has quit IRC | 16:22 | |
| *** zhipeng has quit IRC | 16:58 | |
| *** goldenfri has joined #openstack-cyborg | 18:02 | |
| *** crushil has quit IRC | 19:37 | |
| *** crushil has joined #openstack-cyborg | 19:47 | |
| *** goldenfri has quit IRC | 19:52 | |
| *** goldenfr_ has joined #openstack-cyborg | 20:10 | |
| *** jkilpatr has quit IRC | 21:11 | |
| *** mikeH has quit IRC | 21:57 | |
| *** jkilpatr has joined #openstack-cyborg | 21:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!