Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2019-08-07
03:02:58 s_shogo #info s_shogo
03:03:25 wangzhh Hi
03:03:25 wangzhh #info wangzhh
03:03:35 Sundar Hi all, quite a few things to discuss today. Do you have anything else to add?
03:04:56 Sundar 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 Li_Liu sorry. I will pay attention next time
03:07:04 Li_Liu shall I submit a patch to revert it?
03:07:09 Sundar 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 Sundar 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 Li_Liu I will try to make more time for the team
03:07:50 Sundar Thanks, Li_Liu
03:08:40 Li_Liu So I will submit a patchset to revert my change
03:08:48 Li_Liu shall I ?
03:09:05 Sundar Yes, please
03:09:07 Li_Liu ok
03:09:10 Sundar 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 Li_Liu sure
03:09:56 Sundar 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 Li_Liu I guess xinran will work on it, right?
03:10:55 xinranwang I am working on cyborg side now.
03:11:11 Sundar I don't mean to step on your contribution. I am mostly concerned about the short time and making progress
03:11:37 Li_Liu totally understand
03:11:47 Sundar Li_Liu: we'll work something out. Your contributions and reviews are always welcome.
03:11:59 Li_Liu ok
03:12:50 Sundar Thanks very much, Li_Liu.
03:13:22 Li_Liu np
03:13:27 Sundar 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 xinranwang agree
03:14:46 Sundar OK, will create one. Looks like only one day works: Thu morning China time
03:14:49 Li_Liu I reverted the change I did today. still have a conflict
03:15:40 Li_Liu might need to resolve the conflict manully
03:16:20 Sundar Ok
03:16:26 Sundar #topic bindep
03:16:52 yikun https://review.opendev.org/#/c/674536/
03:16:57 yikun Thanks， sundar
03:17:10 yikun ^ here is the bindep reltead patch
03:17:17 Sundar yikun has introduced the bindep patch: https://review.opendev.org/#/c/674536/ . It installs pciutils as a Cyborg dependency
03:17:24 Sundar Ah yes, thanks yikun
03:18:04 Sundar My question is: since it is really a dependency of the GPU driver, should we put that as a Cyborg dependency?
03:18:42 yikun My idea is that it's the special cmd which will be used by all generic pci device.
03:18:45 yikun so we need it
03:19:35 xinranwang will this depends on OS?
03:19:43 Sundar The operator may disable specific drivers, though.
03:20:17 Sundar xinranwang: Yes, the specific package may vary across distros.
03:20:34 yikun xinranwang: no, the general os (centos, ubuntu) has the same name
03:20:47 yikun https://github.com/openstack/zun/blob/master/bindep.txt#L40
03:21:04 yikun acutually, the zun was also introduced it
03:21:14 yikun So, I think it's a better way
03:21:56 Sundar The package name may be common to Centos and Ubuntu. But do we know about others?
03:22:10 xinranwang why don't we read sysfs instead. like fpga driver did
03:22:58 yikun https://docs.openstack.org/infra/bindep/readme.html#examples
03:23:17 yikun xinranwang: not sure sysfs can be supported completely by other device.
03:23:33 wangzhh xinranwang, we can't find some pci device by sysfs.
03:24:05 Sundar wangzhh: We have /sys/bus/pci . I think you are saying that doesn't have all the info you need?
03:24:09 xinranwang as far as i know, the 'lspci' also read the sysfs.
03:24:16 Yumeng wangzhh: can we also find gpu device by sysfs ?
03:26:21 wangzhh Yep, Sundar, as far as i know, some info like manufacturer， read form another directory by lspci
03:26:36 Sundar 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 Sundar As long as we examine each addition to bindep carefully, we should be ok, I think.
03:28:00 wangzhh Different os have differetnt dir. It's better to use a lib. Key point is
03:28:12 Sundar I have no objections to adding pciutils. Anybody thinks differently?
03:28:22 wangzhh Is pciutils populate?
03:29:17 Sundar wangzhh: are you asking if it is usually installed or populated?
03:30:49 Sundar Is everybody ok with adding pciutils?
03:31:11 xinranwang no objections
03:31:43 wangzhh I'm worried about there are few people maintain and use it? I'm not sure.
03:32:49 yikun wangzhh: lspci is contained by pcituils package
03:32:53 Sundar 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 Sundar *except
03:33:18 wangzhh Ok, fine.
03:33:26 yikun https://launchpad.net/ubuntu/+source/pciutils
03:33:42 Yumeng no objections +1
03:34:10 Sundar #agreed Will adopt bindep approach with pciutils.
03:34:23 Sundar #topic New drivers in Train
03:34:38 Sundar Glad to see many drivers getting proposed as patches
03:35:07 Sundar 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 Sundar Otherwise, it is not clear to the community what devices are involved and what testing needs to be done
03:36:10 Sundar The device hardware may not be available to other contributors. So, it is important to set up CI, I think
03:36:15 Sundar What do you all think?
03:38:14 Sundar wangzhh, yikun, Yumeng: ^
03:38:42 Sundar for GPUs, Ascend, HPTS
03:39:00 yikun 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 Sundar yikun: Understand. But we should probably have some documentation on what is supported for each driver
03:40:19 Sundar For example, we may have some limitations or caveats for one driver but not others
03:41:11 yikun https://docs.openstack.org/cinder/rocky/reference/support-matrix.html
03:41:25 yikun I guess a page looks like it ^
03:41:44 Sundar Good find :)
03:41:44 wangzhh Emm, agree.
03:42:12 Sundar 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 Sundar For Train, though it is past Milestone 2, I think we can make an exception and accept specs even now.
03:45:01 Sundar wangzhh, Yumeng, yikun, Li_Liu, xinranwang, s_shogo: ^
03:45:18 Yumeng ,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 Yumeng Can we focus on the driver code/(make the function work) first and do the ci plans spec/support docs later ?
03:46:09 wangzhh I think this link is a good example.
03:46:26 Yumeng especially after we tested with some results
03:46:57 Sundar 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 Sundar Yumeng: CI plans can come later. But, without a spec, how do we know enough to maintain it?
03:50:23 Sundar Anybody disagree? or think we need exceptions for Train?
03:51:58 Yumeng 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 yikun Agree with yumen, the priority thing is make the driver work.

Earlier   Later