03:00:39 #startmeeting openstack-cyborg 03:00:40 Meeting started Wed Aug 7 03:00:39 2019 UTC and is due to finish in 60 minutes. The chair is Sundar. Information about MeetBot at http://wiki.debian.org/MeetBot. 03:00:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:00:43 The meeting name has been set to 'openstack_cyborg' 03:00:57 o/ 03:01:00 #topic Roll call 03:01:23 Hi all 03:01:38 hi Sundar 03:01:41 Hi all 03:01:52 Hi all 03:02:42 #info Yumeng 03:02:46 #topic Agenda 03:02:48 https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda 03:02:49 #info Li_Liu 03:02:54 #info xinranwang 03:02:58 #info s_shogo 03:03:25 Hi 03:03:25 #info wangzhh 03:03:35 Hi all, quite a few things to discuss today. Do you have anything else to add? 03:04:56 Hi Li_Liu, your contribution of notification code is quite welcome. However, please check with the other contributor before overwriting their code. The patch https://review.opendev.org/#/c/631244/ has hit a merge conflict 03:06:45 sorry. I will pay attention next time 03:07:04 shall I submit a patch to revert it? 03:07:09 Also, as a contributor, it is good to be in communication with the team. Given the regulations in communication, that means mainly IRC meetings. 03:07:42 Apparently, many people are finding this time slot to be a conflict. Please bring that up and ask for a time change. We can work something out. 03:07:44 I will try to make more time for the team 03:07:50 Thanks, Li_Liu 03:08:40 So I will submit a patchset to revert my change 03:08:48 shall I ? 03:09:05 Yes, please 03:09:07 ok 03:09:10 Li_Liu, my suggestion is: given the very short time left, and time constraints on contributors, does it make sense for one of us to adopt the notification functionality with attribution to you? 03:09:48 sure 03:09:56 Though the Nova deadline is early Sep, we effectively need to finish in Aug to give time for other odds and ends 03:10:06 I guess xinran will work on it, right? 03:10:55 I am working on cyborg side now. 03:11:11 I don't mean to step on your contribution. I am mostly concerned about the short time and making progress 03:11:37 totally understand 03:11:47 Li_Liu: we'll work something out. Your contributions and reviews are always welcome. 03:11:59 ok 03:12:50 Thanks very much, Li_Liu. 03:13:22 np 03:13:27 Folks, should we do a doodle pool to find another time for this IRC meeting, as it is a conflict for many people? 03:13:57 agree 03:14:46 OK, will create one. Looks like only one day works: Thu morning China time 03:14:49 I reverted the change I did today. still have a conflict 03:15:40 might need to resolve the conflict manully 03:16:20 Ok 03:16:26 #topic bindep 03:16:52 https://review.opendev.org/#/c/674536/ 03:16:57 Thanks, sundar 03:17:10 ^ here is the bindep reltead patch 03:17:17 yikun has introduced the bindep patch: https://review.opendev.org/#/c/674536/ . It installs pciutils as a Cyborg dependency 03:17:24 Ah yes, thanks yikun 03:18:04 My question is: since it is really a dependency of the GPU driver, should we put that as a Cyborg dependency? 03:18:42 My idea is that it's the special cmd which will be used by all generic pci device. 03:18:45 so we need it 03:19:35 will this depends on OS? 03:19:43 The operator may disable specific drivers, though. 03:20:17 xinranwang: Yes, the specific package may vary across distros. 03:20:34 xinranwang: no, the general os (centos, ubuntu) has the same name 03:20:47 https://github.com/openstack/zun/blob/master/bindep.txt#L40 03:21:04 acutually, the zun was also introduced it 03:21:14 So, I think it's a better way 03:21:56 The package name may be common to Centos and Ubuntu. But do we know about others? 03:22:10 why don't we read sysfs instead. like fpga driver did 03:22:58 https://docs.openstack.org/infra/bindep/readme.html#examples 03:23:17 xinranwang: not sure sysfs can be supported completely by other device. 03:23:33 xinranwang, we can't find some pci device by sysfs. 03:24:05 wangzhh: We have /sys/bus/pci . I think you are saying that doesn't have all the info you need? 03:24:09 as far as i know, the 'lspci' also read the sysfs. 03:24:16 wangzhh: can we also find gpu device by sysfs ? 03:26:21 Yep, Sundar, as far as i know, some info like manufacturer, read form another directory by lspci 03:26:36 I think the risk is low for pciutils, because it is pretty common. But this puts us on a slippery slope to other packages that may not be common. 03:27:29 As long as we examine each addition to bindep carefully, we should be ok, I think. 03:28:00 Different os have differetnt dir. It's better to use a lib. Key point is 03:28:12 I have no objections to adding pciutils. Anybody thinks differently? 03:28:22 Is pciutils populate? 03:29:17 wangzhh: are you asking if it is usually installed or populated? 03:30:49 Is everybody ok with adding pciutils? 03:31:11 no objections 03:31:43 I'm worried about there are few people maintain and use it? I'm not sure. 03:32:49 wangzhh: lspci is contained by pcituils package 03:32:53 wangzhh: I think pciutils is a popular package, available in most common distros. exceptios may be some really tiny or embedded distros, but they will probably not be used in servers 03:33:05 *except 03:33:18 Ok, fine. 03:33:26 https://launchpad.net/ubuntu/+source/pciutils 03:33:42 no objections +1 03:34:10 #agreed Will adopt bindep approach with pciutils. 03:34:23 #topic New drivers in Train 03:34:38 Glad to see many drivers getting proposed as patches 03:35:07 It may be a good idea to ask for a spec, stating he use cases, test plans and plans for CI, I think 03:35:41 Otherwise, it is not clear to the community what devices are involved and what testing needs to be done 03:36:10 The device hardware may not be available to other contributors. So, it is important to set up CI, I think 03:36:15 What do you all think? 03:38:14 wangzhh, yikun, Yumeng: ^ 03:38:42 for GPUs, Ascend, HPTS 03:39:00 the ci support is a good idea, but I prefer we can start to make 3rd party ci support in next release. 03:39:55 yikun: Understand. But we should probably have some documentation on what is supported for each driver 03:40:19 For example, we may have some limitations or caveats for one driver but not others 03:41:11 https://docs.openstack.org/cinder/rocky/reference/support-matrix.html 03:41:25 I guess a page looks like it ^ 03:41:44 Good find :) 03:41:44 Emm, agree. 03:42:12 I think we should require a spec before we agree to maintain the driver. The spec should describe the device, use cases, test plans and documentation plans. What do you all think? 03:43:17 For Train, though it is past Milestone 2, I think we can make an exception and accept specs even now. 03:45:01 wangzhh, Yumeng, yikun, Li_Liu, xinranwang, s_shogo: ^ 03:45:18 ,Sundar, yikun,wangzhh: agree that we need to have some docs like https://docs.openstack.org/cinder/rocky/reference/support-matrix.html. 03:45:53 Can we focus on the driver code/(make the function work) first and do the ci plans spec/support docs later ? 03:46:09 I think this link is a good example. 03:46:26 especially after we tested with some results 03:46:57 Apart from that doc, many projects require a spec before accepting a major feature. When somebody contributes a driver, we all agree to maintain that code. So, we need a spec to understand what we agree to. 03:48:43 Yumeng: CI plans can come later. But, without a spec, how do we know enough to maintain it? 03:50:23 Anybody disagree? or think we need exceptions for Train? 03:51:58 emmm... I think driver maintainance is strongly related to the device, vendors should maintain their own and provide support for users to use.What do you think? 03:54:59 Agree with yumen, the priority thing is make the driver work. 03:55:22 https://docs.openstack.org/cinder/stein/drivers.html and here is also a example to show the driver support in every release 03:56:12 Yes, vendors would support their own drivers. When a driver is comitted to Cyborg repo, we agree to collectively maintain it. For example, for Python 3 migration, driver code can be changed by somebody other than the vendor, right? 03:57:00 Anyways, we can revisit this next meeting, because we are running out of time. 03:57:07 #topic Storyboard 03:57:17 https://storyboard.openstack.org/#!/project/openstack/cyborg 03:58:16 There are lots of topics still open. Please go through it and take up what you can. 03:59:11 Some important things that we need to track: Python 3 migration, fake driver patch (https://review.opendev.org/665318) 03:59:28 testing to make sure that fake driver works with tempest CI (needed for Nova patch merging) 04:00:33 Anything else that we need to track in each meeting going forward? 04:01:45 Sundar: I noticed lots of TODOs in dbapi such as https://github.com/openstack/cyborg/blob/master/cyborg/db/sqlalchemy/api.py#L567 04:02:20 please review the placement report part as well, it's also in critical path. 04:02:37 https://review.opendev.org/#/c/659233/ 04:02:58 Yumeng: True, I was hoping to get to them after the patches merge. If some of you can take up some of those TODOs, that'll be great. 04:03:20 xinranwang: Yes. 04:03:43 OK, we are past the time. 04:04:00 do you want to make them tested and work after V2 and nova-integ patches merged? or are there any other motivations? 04:04:33 ok, we can continue in wechat 04:04:42 Yumeng: That's what I thought originally. But the basic db patch has already merged for Cyborg. So, we can start filing patches for db changes 04:05:02 ok 04:05:03 I have removed these exception in placement report patch. it can wirte the db correctly 04:05:27 xinranwang:ok great! 04:05:33 I'll create storyboard tasks for these TODOs 04:05:55 Thanks, everybody. Have a good day or night, wherever you may be :) 04:06:02 #endmeeting