15:03:38 #startmeeting openstack-cyborg 15:03:38 Meeting started Wed Apr 5 15:03:38 2017 UTC and is due to finish in 60 minutes. The chair is zhipeng_. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:03:41 The meeting name has been set to 'openstack_cyborg' 15:03:55 #info zhipeng crushil 15:04:02 who else do we have at the meeting ? 15:10:34 o/ 15:10:36 sorry I'm late 15:12:08 no problem,just saw your patch 15:12:16 #topic BP discussion 15:12:54 I must apologize that due to the cloudnativecon week, I have not been attentive to the api BP 15:13:09 will get to it starting tmr I hope 15:13:29 crushil jkilpatr could you guys walk through the updates ? 15:13:44 Sure 15:14:08 crushil, you first? 15:14:15 yup 15:14:28 Updated the bp for the generic driver implementation and trying to incorporate all the changes that were requested 15:15:08 Did some reviews on other BPs as well and waiting for the BP owners to come back with a response 15:15:53 crushil cool man, any outstanding issues at the moment ? 15:15:58 The generic driver implementation bp is at https://review.openstack.org/#/c/447257/ 15:16:19 zhipeng_, Nope, just need more review comments atm 15:16:34 great :) 15:18:02 jkilpatr how about your updates ? 15:18:34 So I still need to address a review from a Friday. It's not going to be the conductor's responsibility to attach accelerators, so I need to remove it from that part of the loop 15:18:51 then I think I'll be taking the suggestion to move setup responsiblities out of the conductor. 15:19:15 for the time being I guess we can maintain a directory of setup playbooks and document how to use them. 15:19:50 I also need to actually write the caching stuff we talked about in the last meeting. Might try and get through that today 15:19:52 that's all. 15:20:19 i don't remember we had discussion on moving out setup functionalities 15:20:34 is it from the review ? 15:20:48 zhipeng_, it's in the review comments. 15:21:15 my network is dreadfully slow now ... so comments from _gryf ? 15:21:33 Roman doesn't like the idea of having a program run off and install it's own dependencies. Which I can understand. 15:21:42 i thought we had a understanding that agent could do the ansible stuff 15:23:17 okey i will dig into Roman's comment later 15:24:17 There are arguments from both sides, on one hand ease of setup, on the other the potential conseqences of cyborg running wild with root. 15:24:48 in the end we're planning on making the same playbooks and just having a human press the button instead of the agent. 15:24:52 so if we do the setup as a out-of-band operation 15:25:07 okey 15:26:29 but I do have some scenarios that maybe still the agent should do the setup, despite of the security concerns 15:27:24 for example for some dataplane virtualization techniques, you could compose a set up virtual functions into one bigger function 15:27:47 a case wouldbe to compose a virtual FW on a intelligent NIC card 15:28:25 using different dedicated small virtual networking functions which will do q-in-q, switching respectively 15:29:02 jkilpatrt I think the overall question is that , could we have a compromise between the two sides ? 15:31:01 zhipeng_, I think we could find some sort of compromise I'm just not sure where to draw the line 15:32:00 I was thinking the line could be where the root privilege is required 15:32:24 if the root is required on the host side, then maybe it is good, as Roman suggested, to leave to the humans 15:32:39 that sounds reasonable enough. 15:32:40 but if it is root privilege on the smart device 15:33:06 then we could, at the moment, assume that the conductor could perform the setup with root privilege 15:33:31 it has security concerns as well, no doubt, but i think we could deal with it later on 15:34:30 you're talking about permissions levels on the accelerator itself? What is the "smart device" ? 15:35:51 yes i was. smart device like intelligent NICs I referred to 15:36:13 there are FPGA enabled devices that you could program the "micro" virtual functions 15:36:27 deploy them in different ways to compose different functionalities 15:36:49 it is not widely used yet, but I think it would be a major use case later on 15:37:08 I know FPGA's can be deployed like that but I never thought about user levels on them. 15:37:08 for example in edge computing, where you could dynamically compose your network dataplane 15:37:46 that was just my thinking 15:38:09 it makes sense, just never considered it that way. 15:38:56 if we could have cyoborg agent setup an ansible playbook on a rasberry pie 15:39:03 that would be supper awesome :P 15:39:22 but why? 15:39:49 (just thinking out loud) 15:40:12 never mind the pie example 15:40:34 so I think I will also comment on the patch, to see what's _gryf's take on this 15:41:17 if in the end , the dynamic composition FPGA use case is still too far fetch, then we could just have the regular playbook procedure 15:43:04 I think that's fine for now. Maybe add some notifications to the operator that things need to be setup. 15:43:14 I think we could detect new accelerators without root 15:43:39 yes that is ture 15:43:43 true ... 15:43:49 fat fingers 15:44:00 #topic AoB 15:44:09 okey any other buisness or topics 15:46:13 Not from me 15:48:40 not from me either 15:48:45 okey thank you guys for the great work on the bp patches, let's conclude the meeting earlier today :) 15:48:53 see you guys on gerrit :P 15:48:58 #endmeeting