Earlier  
Posted Nick Remark
#openstack-cyborg - 2017-04-05
15:03:39 openstack Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:41 openstack The meeting name has been set to 'openstack_cyborg'
15:03:55 zhipeng_ #info zhipeng crushil
15:04:02 zhipeng_ who else do we have at the meeting ?
15:10:34 jkilpatr o/
15:10:36 jkilpatr sorry I'm late
15:12:08 zhipeng_ no problem,just saw your patch
15:12:16 zhipeng_ #topic BP discussion
15:12:54 zhipeng_ I must apologize that due to the cloudnativecon week, I have not been attentive to the api BP
15:13:09 zhipeng_ will get to it starting tmr I hope
15:13:29 zhipeng_ crushil jkilpatr could you guys walk through the updates ?
15:13:44 crushil Sure
15:14:08 jkilpatr crushil, you first?
15:14:15 crushil yup
15:14:28 crushil Updated the bp for the generic driver implementation and trying to incorporate all the changes that were requested
15:15:08 crushil Did some reviews on other BPs as well and waiting for the BP owners to come back with a response
15:15:53 zhipeng_ crushil cool man, any outstanding issues at the moment ?
15:15:58 crushil The generic driver implementation bp is at https://review.openstack.org/#/c/447257/
15:16:19 crushil zhipeng_, Nope, just need more review comments atm
15:16:34 zhipeng_ great :)
15:18:02 zhipeng_ jkilpatr how about your updates ?
15:18:34 jkilpatr 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 jkilpatr then I think I'll be taking the suggestion to move setup responsiblities out of the conductor.
15:19:15 jkilpatr for the time being I guess we can maintain a directory of setup playbooks and document how to use them.
15:19:50 jkilpatr 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 jkilpatr that's all.
15:20:19 zhipeng_ i don't remember we had discussion on moving out setup functionalities
15:20:34 zhipeng_ is it from the review ?
15:20:48 jkilpatr zhipeng_, it's in the review comments.
15:21:15 zhipeng_ my network is dreadfully slow now ... so comments from _gryf ?
15:21:33 jkilpatr 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 zhipeng_ i thought we had a understanding that agent could do the ansible stuff
15:23:17 zhipeng_ okey i will dig into Roman's comment later
15:24:17 jkilpatr 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 jkilpatr 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 zhipeng_ so if we do the setup as a out-of-band operation
15:25:07 zhipeng_ okey
15:26:29 zhipeng_ but I do have some scenarios that maybe still the agent should do the setup, despite of the security concerns
15:27:24 zhipeng_ for example for some dataplane virtualization techniques, you could compose a set up virtual functions into one bigger function
15:27:47 zhipeng_ a case wouldbe to compose a virtual FW on a intelligent NIC card
15:28:25 zhipeng_ using different dedicated small virtual networking functions which will do q-in-q, switching respectively
15:29:02 zhipeng_ jkilpatrt I think the overall question is that , could we have a compromise between the two sides ?
15:31:01 jkilpatr zhipeng_, I think we could find some sort of compromise I'm just not sure where to draw the line
15:32:00 zhipeng_ I was thinking the line could be where the root privilege is required
15:32:24 zhipeng_ 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 jkilpatr that sounds reasonable enough.
15:32:40 zhipeng_ but if it is root privilege on the smart device
15:33:06 zhipeng_ then we could, at the moment, assume that the conductor could perform the setup with root privilege
15:33:31 zhipeng_ it has security concerns as well, no doubt, but i think we could deal with it later on
15:34:30 jkilpatr you're talking about permissions levels on the accelerator itself? What is the "smart device" ?
15:35:51 zhipeng_ yes i was. smart device like intelligent NICs I referred to
15:36:13 zhipeng_ there are FPGA enabled devices that you could program the "micro" virtual functions
15:36:27 zhipeng_ deploy them in different ways to compose different functionalities
15:36:49 zhipeng_ it is not widely used yet, but I think it would be a major use case later on
15:37:08 jkilpatr I know FPGA's can be deployed like that but I never thought about user levels on them.
15:37:08 zhipeng_ for example in edge computing, where you could dynamically compose your network dataplane
15:37:46 zhipeng_ that was just my thinking
15:38:09 jkilpatr it makes sense, just never considered it that way.
15:38:56 zhipeng_ if we could have cyoborg agent setup an ansible playbook on a rasberry pie
15:39:03 zhipeng_ that would be supper awesome :P
15:39:22 jkilpatr but why?
15:39:49 zhipeng_ (just thinking out loud)
15:40:12 zhipeng_ never mind the pie example
15:40:34 zhipeng_ so I think I will also comment on the patch, to see what's _gryf's take on this
15:41:17 zhipeng_ 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 jkilpatr I think that's fine for now. Maybe add some notifications to the operator that things need to be setup.
15:43:14 jkilpatr I think we could detect new accelerators without root
15:43:39 zhipeng_ yes that is ture
15:43:43 zhipeng_ true ...
15:43:49 zhipeng_ fat fingers
15:44:00 zhipeng_ #topic AoB
15:44:09 zhipeng_ okey any other buisness or topics
15:46:13 crushil Not from me
15:48:40 jkilpatr not from me either
15:48:45 zhipeng_ okey thank you guys for the great work on the bp patches, let's conclude the meeting earlier today :)
15:48:53 zhipeng_ see you guys on gerrit :P
15:48:58 zhipeng_ #endmeeting
15:49:00 openstack Meeting ended Wed Apr 5 15:48:58 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:49:01 openstack Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-04-05-15.03.html
15:49:02 openstack Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-04-05-15.03.txt
15:49:04 openstack Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-04-05-15.03.log.html
#openstack-cyborg - 2017-04-12
14:01:46 ewchan Hi. This is Eugene Chan from Huawei. I would like to be an observer of the meeting today.
14:02:29 zhipeng cool :)
14:02:37 NokMikeR HI Eugene, welcome.
14:02:39 zhipeng our meeting will start one hour later
14:02:45 zhipeng but we could always chat :P
14:04:34 ewchan oh. thanks. it must be the dst changes. as it listed as 10am est in the cyborg site.
14:05:10 zhipeng i forgot to change lol
14:05:19 zhipeng thx for reminding
14:05:43 ewchan no problem :)
14:06:00 NokMikeR was the meeting normally held at 15:00 UTC?
14:06:29 zhipeng NokMikeR yes I think at least for the Pike cycle
15:01:29 crushil \o
15:06:50 zhipengh[m] Hey guys
15:07:04 zhipengh[m] My home network is very unstable
15:07:26 zhipengh[m] #startmeeting openstack-cyborg
15:07:27 openstack Meeting started Wed Apr 12 15:07:26 2017 UTC and is due to finish in 60 minutes. The chair is zhipengh[m]. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:07:28 openstack Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:07:31 openstack The meeting name has been set to 'openstack_cyborg'
15:07:53 zhipengh[m] #topic BP outstanding issues

Earlier   Later