| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-06-07 | |||
| 15:23:13 | zhipeng_ | anything else from you guys on the open spec ? | |
| 15:23:33 | crushil | nope | |
| 15:23:51 | zhipeng_ | great | |
| 15:23:58 | zhipeng_ | #topic initial code development | |
| 15:24:05 | zhipeng_ | so, any roadblocks | |
| 15:24:39 | jkilpatr | been trying to understand oslo rpc and message passing and start structuring the conductor/agent | |
| 15:24:52 | zhipeng_ | sounds like a great start :) | |
| 15:25:02 | crushil | I have created stubs and I will push them up by the end of the week | |
| 15:25:11 | zhipeng_ | great ! | |
| 15:25:18 | jkilpatr | crushil, sounds good. | |
| 15:26:03 | zhipeng_ | let's do small pieces like Justin suggested | |
| 15:26:09 | crushil | I will fill them out rebased on top of the API and agent patches | |
| 15:26:10 | jkilpatr | so a lot of what we will be doing involves rpc between different components, so people with integrating parts need to talk to each other about interfaces | |
| 15:26:19 | jkilpatr | I don't think we should be too worried about a stable internal interface | |
| 15:26:29 | zhipeng_ | yes I agree | |
| 15:27:04 | zhipeng_ | oslo.messaging could provide everything we need | |
| 15:27:46 | jkilpatr | well sometimes we need rpc for example the driver should be called by the agent over rpc I'm thinking (we could invoke directly but I'm not sure if I want to do that) | |
| 15:29:38 | zhipeng_ | i think it should be done over rpc | |
| 15:29:57 | zhipeng_ | unless, we gave driver restful apis ? | |
| 15:30:31 | jkilpatr | I don't think that's the right application here. Our internal code needs to be more tightly integrated than restfulness allows. | |
| 15:30:45 | zhipeng_ | yep | |
| 15:31:07 | zhipeng_ | so rpc should be fine here | |
| 15:31:27 | zhipeng_ | i think at the moment, it is agent talking to the generic driver | |
| 15:31:50 | zhipeng_ | later on, we should design something like the neutron ml2 driver interface | |
| 15:32:29 | zhipeng_ | that every driver, vendor or not, implements the interface which rpc calls will go through | |
| 15:32:34 | zhipeng_ | in a rather standard way | |
| 15:33:29 | rushil | Ok. So, are we going to follow the neutron model vs the nova/cinder model? | |
| 15:33:47 | zhipeng_ | i think more like the neutron moddel | |
| 15:33:55 | zhipeng_ | for out-of-tree drivers | |
| 15:34:03 | rushil | But isn't that too complicated | |
| 15:34:09 | zhipeng_ | cinder and nova are mostly in-tree maintained drivers | |
| 15:34:20 | zhipeng_ | it won't be too complicated for us i think | |
| 15:34:40 | zhipeng_ | neutron is complicated because they have to define the type drivers and mechanism drivers | |
| 15:34:42 | rushil | Well, cinder has out of tree drivers based on whether you have CI or not | |
| 15:35:04 | zhipeng_ | I think in-tree drivers also requires the CI | |
| 15:35:14 | zhipeng_ | otherwise the cinder team removes your driver | |
| 15:35:38 | rushil | No, they just make it unsupported i.e. move it out of tree | |
| 15:35:54 | zhipeng_ | for us, as long as it is PCIe communicated devices, the driver interface won't be too complicated | |
| 15:36:12 | zhipeng_ | but if we need to support extra protocols, that is where things will get wild | |
| 15:36:24 | zhipeng_ | rushil ah okey | |
| 15:36:25 | rushil | Ok. I just want to make sure we don't make things more complicated than they should be | |
| 15:36:37 | zhipeng_ | yes that is always our goal | |
| 15:36:38 | jkilpatr | I can agree on a standard rpc interface but that's less complicated than I think you are making it out to be. | |
| 15:36:49 | zhipeng_ | we even wanted to skip the conductor :P | |
| 15:37:14 | jkilpatr | and I nearly got away with it too! | |
| 15:37:21 | zhipeng_ | jkilpatr haha | |
| 15:37:40 | rushil | Lol | |
| 15:39:26 | zhipeng_ | rushil the cyborg ml2 driver would be modeled from your generic driver implementation :P | |
| 15:40:37 | rushil | I wouldn't call it ml2 driver though | |
| 15:40:52 | zhipeng_ | of course we will have another name for it | |
| 15:41:14 | zhipeng_ | aluminum drivers :P | |
| 15:41:24 | zhipeng_ | for cyborg robots | |
| 15:41:45 | rushil | Hehe | |
| 15:42:36 | jkilpatr | Anyways I'll try have a stub up this week (conductor) and then agent next week. | |
| 15:42:46 | jkilpatr | depends on how other tasks go for me. | |
| 15:43:44 | rushil | jkilpatr: Cool | |
| 15:43:50 | zhipeng_ | sounds great, i got another colleague working on cyborg this week, so api code will be developed in parallel | |
| 15:44:09 | rushil | Awesome | |
| 15:44:10 | zhipeng_ | hopefully when we settled the spec, the initial code will come out | |
| 15:44:21 | zhipeng_ | and we could iterate over | |
| 15:44:48 | zhipeng_ | #topic AoB | |
| 15:44:52 | zhipeng_ | any other topics | |
| 15:44:59 | rushil | Btw our group at Lenovo sent out initial emails to vendors to get their drivers aligned with cyborg | |
| 15:45:20 | zhipeng_ | wow | |
| 15:45:24 | zhipeng_ | that is awesome | |
| 15:45:45 | rushil | I'll keep you guys posted on that | |
| 15:45:51 | zhipeng_ | could you disclose the vendor names for now ? | |
| 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 | zhipeng | #startmeeting openstack-cyborg | |
| 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: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/ | |