14:11:47 #startmeeting openstack-cyborg 14:11:48 Meeting started Wed Aug 15 14:11:47 2018 UTC and is due to finish in 60 minutes. The chair is Li_Liu. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:11:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:11:52 The meeting name has been set to 'openstack_cyborg' 14:12:01 #topic Roll Call 14:12:02 #info Sundar 14:12:04 #info Coco_gao 14:12:08 #info Li_Liu 14:12:15 #info wangzhh 14:12:39 #Topic Status Update 14:12:42 #info xinran 14:12:54 https://review.openstack.org/#/q/status:open%20project:openstack/cyborg 14:13:53 I see xinran just updated https://review.openstack.org/#/c/564968/ 14:14:18 Please help reviewing this 14:14:29 I will test my object code with agent part tomorrow. 14:14:42 Yes I just updated it including to the new api design 14:14:53 There is no commit on that yet right Coco_gao? 14:15:01 Are we aiming code changes for Stein release, since the Rocky cycle is past code freeze? 14:15:15 thanks a lot xinran 14:15:23 past? 14:15:44 But I am not sure how we handle the quota granularity 14:16:00 #info shaohe_feng_ 14:16:44 deployable is OK. 14:16:54 Coco_gao: #link https://releases.openstack.org/rocky/schedule.html July 27 was feature freeze. We are past the RC1 milestone 14:16:58 for granularity at present 14:17:35 However we do quotas now, it should be upgradable to the per-RC quota that is coming in Nova. 14:19:19 It is OK for placement do quota in openstack 14:20:09 Sundar, I will double check on that, but there is another window Aug20-24 for Final RCs 14:21:05 We hope we can squeeze CoCo's stuff in, as these code are not affecting external customers/users/components anyways 14:22:51 And zhenghao's part is quite related to my part, the agent code need to update either. 14:24:49 If we commit before August 20, is that possible to catch up the Final RCs? 14:24:56 ok, I can see the only major pieces that are missing are 1. Coco_gao and wangzhh's code 2. merging xinran's code 14:25:20 I think you can, but I need to double check for you 14:25:37 Li_Liu: Sundar: how is the new FPGA driver? 14:26:16 Will Coco-gao's code include driver-API interaction via OVOs, and reflect the os-acc-related aspects too? 14:26:55 it is OVOs. :) 14:27:00 shahe_feng_, are you talking about https://review.openstack.org/#/c/584170/? 14:27:18 shaohe: The OPAE-based driver needs to be tested well before committing. 14:27:36 Li_Liu: yes. 14:28:02 I and zhenghao will try our best. 14:28:35 I think it still needs to be tested against CI at least 14:28:54 Sundar: Is it necessary for we to update the old drivers? 14:29:05 Yeah, I think so 14:29:20 Coco_gao: thanks. hard work. 14:29:28 Coco_gao: Yes. ლ(╹◡╹ლ) 14:29:53 Sundar: the agent depend on the driver. 14:30:18 Just curious: Why do we want to get code into Rocky at this stage? Aren't we better off getting agreement on the overall flow and doing it properly? 14:30:25 In the agent , we need the code to be more general rather than FPGA specific. 14:30:56 Sundar, that's an option if there are no hurry. 14:31:04 I don't know. 14:32:00 Sundar: do you have better design for the new refactor? 14:32:18 Coco_gao: agreed that the agent is not FPGA-specific. The drive-agent API should not be device-specific either. Also, there are requests to let the driver tell the agent about custom traits for its device. 14:33:20 shaohe: I have some ideas on the driver API along the lines above, and addressing the diff update etc. I am writing it as a new spec, to be out this week (for Stein PTG). 14:33:27 Hope to get input from all of you! 14:38:00 Also, is anybody thinking about the test framework that we have today? How do we get Zuul to work with real devices? 14:41:07 Should Zuul test real devices? 14:41:47 Procedurally, trying to get something of this size into Rocky is a no-go. 14:43:20 I think to test real devices you would need a third party CI. You can't count on the nodes in the pool managed by zuul for tox- and devstack-based tests to have devices. 14:44:37 May be we should create fake devices in the testing framework for every supported device type. Like shaohe's fake FPGAs. 14:44:43 Can you fake the device information for CI? 14:46:40 we had better do some fake 14:46:42 Li_liu: Now we fake them for UT. 14:46:55 Yeah, we need to make sure the fake information is same with the what we get from devices. 14:47:13 If we do create fake devices, they even need to simulate timeouts and unresponsiveness, to test various code paths. 14:47:30 efried, I get your point, we are just keep committing, if we can make to Rocky, that's cool, if we can not, it will just slide into S 14:48:36 Sundar: for hardware devices a third party CI is better 14:48:39 unlike other projects, Cyborg is still not in its usable stage yet. Keep having code to make it mature is the key right now 14:49:00 The project has already forked, so you would have to explicitly backport changes to stable/rocky. That is the thing I'm saying you shouldn't do. 14:49:12 Keep committing to master (which is Stein at this point) 14:49:37 my consideration is, if there are no urgent, I should work with Sundar first to get the spec will recognized by others. 14:49:49 well 14:50:07 ++ to creating fixtures for functional tox-based tests. 14:50:45 but 3 part CI need more resource/effort to maintain 14:51:10 yup 14:52:09 Li_Liu, What should I do next? 14:52:34 3rd party CI should be maintained by device vendors IMO, openstack CI should just keep the fake devices 14:53:19 Coco_gao, if you guys think the time is too tight until Aug 20. just slide the feature into S. 14:53:35 so that you have the time to refine your documentation and code 14:57:28 ok, it's time to wrap up 14:57:48 #todo merge xinran's patch 14:58:35 #todo Coco_gao and wangzhh keep working on their patch, but does not have to make into R 14:59:05 Bye 14:59:39 #todo OPAE PFGA patch needs to be refined for CI and fake the devices if necessary 15:00:48 Sundar, are you going to have a new spec to replace 561849 ? 15:03:50 I will end the meeting for now 15:03:55 #endmeeting