| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-08-07 | |||
| 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 | wangzhh | Emm, agree. | |
| 03:41:44 | Sundar | Good find :) | |
| 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. | |
| 03:55:22 | yikun | 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 | Sundar | 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 | Sundar | Anyways, we can revisit this next meeting, because we are running out of time. | |
| 03:57:07 | Sundar | #topic Storyboard | |
| 03:57:17 | Sundar | https://storyboard.openstack.org/#!/project/openstack/cyborg | |
| 03:58:16 | Sundar | There are lots of topics still open. Please go through it and take up what you can. | |
| 03:59:11 | Sundar | Some important things that we need to track: Python 3 migration, fake driver patch (https://review.opendev.org/665318) | |
| 03:59:28 | Sundar | testing to make sure that fake driver works with tempest CI (needed for Nova patch merging) | |
| 04:00:33 | Sundar | Anything else that we need to track in each meeting going forward? | |
| 04:01:45 | Yumeng | 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 | xinranwang | please review the placement report part as well, it's also in critical path. | |
| 04:02:37 | xinranwang | https://review.opendev.org/#/c/659233/ | |
| 04:02:58 | Sundar | 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 | Sundar | xinranwang: Yes. | |
| 04:03:43 | Sundar | OK, we are past the time. | |
| 04:04:00 | Yumeng | 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 | Yumeng | ok, we can continue in wechat | |
| 04:04:42 | Sundar | 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 | Yumeng | ok | |
| 04:05:03 | xinranwang | I have removed these exception in placement report patch. it can wirte the db correctly | |
| 04:05:26 | Yumeng | xinranwang:ok great! | |
| 04:05:33 | Sundar | I'll create storyboard tasks for these TODOs | |
| 04:05:55 | Sundar | Thanks, everybody. Have a good day or night, wherever you may be :) | |
| 04:06:02 | Sundar | #endmeeting | |
| 04:06:03 | openstack | Meeting ended Wed Aug 7 04:06:02 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 04:06:04 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-08-07-03.00.html | |
| 04:06:05 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-08-07-03.00.txt | |
| 04:06:06 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-08-07-03.00.log.html | |
| 04:06:23 | s_shogo | sorry , next week ( 8/10-19), we (NTT group) take a vacation on the whole. I'm afraid I will be absent from IRC chat and so on. | |