| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2017-03-29 | |||
| 15:47:45 | zhipeng | I think setting a deadline/milestone would be a good idea | |
| 15:47:54 | _gryf | that fine. | |
| 15:47:56 | zhipeng | so that everyone on the same page and pace | |
| 15:48:05 | zhipeng | others ? | |
| 15:48:20 | ttk2[m] | As long as it's not too tight. | |
| 15:48:22 | crushil | So, for current specs, should we say EOR should be the deadline? | |
| 15:48:28 | zhipeng | (if we have a milestone then maybe we need a sprint someday ...) | |
| 15:48:41 | zhipeng | crushil for specs that would be too relax | |
| 15:48:49 | zhipeng | we need to get code in for Pike | |
| 15:48:59 | crushil | I meant implementation of the specs | |
| 15:49:07 | zhipeng | yes that'd agre | |
| 15:49:18 | zhipeng | I would agree | |
| 15:49:23 | ttk2[m] | Let's just put a deadline on specs for now. | |
| 15:49:29 | zhipeng | Apr 15th ? | |
| 15:49:46 | ttk2[m] | That's what 3 meetings? | |
| 15:49:57 | crushil | lol | |
| 15:50:02 | zhipeng | sounds about right | |
| 15:50:10 | zhipeng | too relax or too tight ? lol | |
| 15:50:40 | crushil | I think for most of the specs, the owners know what needs to be added | |
| 15:50:57 | crushil | So, it is slightly on the more relaxed side | |
| 15:51:01 | zhipeng | it is the reviews that takes time | |
| 15:51:25 | crushil | Fair | |
| 15:51:25 | zhipeng | _gryf we are not that famous project so we could move faster XD | |
| 15:51:31 | _gryf | which obviously means slipping to the next release :> | |
| 15:51:40 | crushil | Let's do April 15th then | |
| 15:51:52 | ttk2[m] | +1 | |
| 15:52:10 | zhipeng | #vote Apr 15th as the deadline for specs | |
| 15:52:21 | zhipeng | okey wrong cmd ... | |
| 15:52:32 | zhipeng | but anyway we should all agree on this | |
| 15:52:46 | zhipeng | #info Apr 15th for the first milestone on spec freeze | |
| 15:53:01 | zhipeng | #agreed Apr 15th for the first milestone on spec freeze | |
| 15:53:31 | zhipeng | great discussions folks | |
| 15:53:36 | zhipeng | any other buisness ? | |
| 15:54:36 | zhipengh[m] | My Chromebook just died.. | |
| 15:54:58 | crushil | zhipengh[m], Get a real computer. :P | |
| 15:55:11 | zhipengh[m] | lol give me money | |
| 15:58:18 | zhipengh[m] | Okey if no other biz, let me try to end meeting using this handle... Not sure it will work | |
| 15:58:27 | zhipengh[m] | #endmeeting | |
| 15:59:14 | zhipengh[m] | Bummer... | |
| 15:59:48 | _gryf | #endmeeting | |
| 15:59:56 | _gryf | lol | |
| 17:51:01 | zhipeng | the longest meeting ever... | |
| 17:51:05 | zhipeng | #endmeeting | |
| 17:51:07 | openstack | Meeting ended Wed Mar 29 17:51:05 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:51:08 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-03-29-15.00.html | |
| 17:51:09 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-03-29-15.00.txt | |
| 17:51:10 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2017/openstack_cyborg.2017-03-29-15.00.log.html | |
| #openstack-cyborg - 2017-04-05 | |||
| 15:03:03 | crushil | \o | |
| 15:03:18 | zhipeng_ | hey | |
| 15:03:28 | zhipeng_ | let's go | |
| 15:03:38 | zhipeng_ | #startmeeting openstack-cyborg | |
| 15:03:38 | openstack | 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 | 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 | |