| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-06-07 | |||
| 15:45:57 | zhipeng_ | or should we wait until later | |
| 15:46:14 | rushil | The usual suspects | |
| 15:46:35 | zhipeng_ | e.g ? | |
| 15:46:47 | rushil | Nvidia, AMD | |
| 15:47:00 | rushil | And smaller ones like Micron | |
| 15:47:29 | zhipeng_ | cool ! | |
| 15:47:30 | rushil | I'll let y'all know when they are committed to contributing code | |
| 15:47:40 | zhipeng_ | great :) | |
| 15:50:41 | zhipeng_ | okey if there are no other topics, we go to the usual long slumber ~~ | |
| 15:50:56 | zhipeng_ | will try to remember to close the meeting an hour later | |
| 15:51:05 | crushil | Cool, thanks zhipeng_ | |
| 17:00:56 | zhipeng_ | #endmeeting | |
| 17:00:58 | openstack | Meeting ended Wed Jun 7 17:00:56 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:00:59 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-06-07-15.00.html | |
| 17:01:00 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-06-07-15.00.txt | |
| 17:01:01 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-06-07-15.00.log.html | |
| #openstack-cyborg - 2017-06-09 | |||
| 12:36:33 | jkilpatr | https://docs.google.com/presentation/d/1cDIhkfFBoIME-DQobACaBmU4qWILJ_sW3chEulIP7ZM/edit#slide=id.p | |
| 12:36:34 | jkilpatr | probably useful | |
| 13:21:46 | jkilpatr | zhipengh[m], so I've been thinking should the API be stateless? AKA it gets everything from the conductor, if we do things that way then when we want to support HA we only have to make the conductor HA everything else is already distributed. | |
| 13:21:54 | jkilpatr | but premature optimization is the root of all evil and all that. | |
| 13:25:30 | zhipengh[m] | API stateless meaning we won't have small dB for API right ? | |
| 13:26:41 | jkilpatr | zhipengh[m], that means no cache which puts more load on other components. Everything has a trade off. | |
| 13:53:13 | zhipengh[m] | Let me think about that a little bit | |
| #openstack-cyborg - 2017-06-14 | |||
| 14:35:06 | jkilpatr | somehow oslo config is more complicated than messaging. | |
| 14:59:58 | crushil | \o | |
| 15:00:39 | zhipeng | hi guys | |
| 15:01:19 | 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:19 | zhipeng | #startmeeting openstack-cyborg | |
| 15:01:20 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 15:01:22 | openstack | The meeting name has been set to 'openstack_cyborg' | |
| 15:01:37 | zhipeng | #topic BP discussion | |
| 15:01:55 | zhipeng | #info the api spec has been updated to reflect the latest comment | |
| 15:02:05 | zhipeng | #link https://review.openstack.org/#/c/445814/ | |
| 15:03:14 | zhipeng | plz help review it, would be nice to merge it by the end of this week | |
| 15:04:22 | zhipeng | and then I think I will take over the cyborg-nova interaction spec | |
| 15:06:08 | zhipeng | any thoughts on the api spec so far ? | |
| 15:06:13 | crushil | zhipeng, Will do | |
| 15:06:26 | crushil | Need to look at the API spec | |
| 15:06:58 | zhipeng | okey no problem | |
| 15:07:05 | zhipeng | moving on to the next topic | |
| 15:07:12 | zhipeng | #topic code development process | |
| 15:07:21 | zhipeng | crushil how's the code going ? | |
| 15:08:22 | 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:54 | jkilpatr | morning everyone. | |
| 15:09:10 | jkilpatr | Conductor is very stubby working on getting it hooked up to rabbit today. | |
| 15:09:11 | zhipeng | morning :) | |
| 15:09:45 | zhipeng | crushil have you submitted the code yet ? | |
| 15:10:10 | jkilpatr | yup he did on sudnay | |
| 15:10:15 | jkilpatr | sunday* | |
| 15:10:19 | crushil | Yup | |
| 15:10:38 | crushil | Morning jkilpatr | |
| 15:10:44 | zhipeng | oh did not see that yet | |
| 15:11:13 | zhipeng | well there is a thought when I update the api spec today | |
| 15:11:23 | 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:49 | zhipeng | that the generic driver should morph into a standalone library for local and remote accelerator attach/detach | |
| 15:12:19 | jkilpatr | so that means we have attach/detach library and then the pci passthrough driver build ontop of it? | |
| 15:12:23 | zhipeng | like os-brick | |
| 15:12:35 | jkilpatr | ok no idea what os-brick is | |
| 15:13:31 | zhipeng | every cinder driver has to do attach/detach on its own | |
| 15:13:31 | zhipeng | back in the days | |
| 15:13:31 | zhipeng | so the background story is | |
| 15:13:31 | zhipeng | yes, just import the lib and use it | |
| 15:13:39 | zhipeng | either iSCSI, FC, or what have you | |
| 15:14:11 | zhipeng | then cinder project extract that part of code out and formed a new sub project called os-brick | |
| 15:14:23 | zhipeng | bascially provide a common lib for the attach/detach | |
| 15:14:39 | zhipeng | the benefit is that, you could use it even Nova is not involved | |
| 15:14:54 | zhipeng | for example attach a volume for baremetal host | |
| 15:15:45 | zhipeng | and cinder driver could just include the lib and call the functions they need | |
| 15:17:36 | crushil | zhipeng, So, are you proposing we should move our generic driver code eventually into something like OS-brick? | |
| 15:17:59 | zhipeng | yes that is my current thinking | |
| 15:18:12 | zhipeng | in the near future | |
| 15:18:46 | crushil | I don't understand why though? | |
| 15:19:27 | jkilpatr | for the sake of abstraction | |
| 15:19:38 | jkilpatr | instead of having to attach.nvidiagraphicsdriver | |
| 15:19:49 | zhipeng | coz currently you are defining the basic operations for the drivers right ? | |
| 15:19:53 | jkilpatr | we would do attach(nvidiagraphics driver object) | |
| 15:20:15 | 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:24 | zhipeng | yep | |
| 15:20:51 | jkilpatr | too much abstraction is counterproductive and I see that in a lot of openstack projects, but this level makes sense. | |
| 15:21:40 | crushil | Ok, we can talk more about it as the design progresses | |
| 15:21:58 | jkilpatr | I find it easier to write somthing monolithic then I understand how to break it out easier | |
| 15:22:08 | zhipeng | yes of course :) | |
| 15:22:34 | zhipeng | haha | |
| 15:23:07 | zhipeng | enough of the microservice hype | |
| 15:24:35 | 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:42 | jkilpatr | in general do what makes sense. | |
| 15:25:09 | jkilpatr | Anyways back on topic. RPC vs messaging vs direct linking | |
| 15:25:19 | zhipeng | indeed | |
| 15:25:47 | 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:26:08 | jkilpatr | in general I think API -> conductor should be RPC | |
| 15:26:19 | jkilpatr | and conductor -> agents should be message passing | |
| 15:26:32 | jkilpatr | and then agents -> drivers should be just direct linking (we import the python modules on the same machine) | |
| 15:27:06 | zhipeng | i think it makes sense on the agent->driver side | |
| 15:27:08 | 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:20 | zhipeng | but considering scaling problem, conductor should still rpc to agent ? | |
| 15:29:45 | 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:51 | jkilpatr | where I'd argue it really does not belong | |
| 15:30:23 | 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:33 | jkilpatr | opinions on this are appreciated. | |
| 15:31:28 | zhipeng | as far as I know, when we deploy cyborg, conductor is more than likely on a different node than the agent | |