| *** rajm has joined #cip | 07:47 | |
| *** toscalix has joined #cip | 08:14 | |
| *** pave1 has joined #cip | 08:58 | |
| *** vidda has joined #cip | 08:59 | |
| szlin | #startmeeting CIP IRC weekly meeting | 09:00 |
|---|---|---|
| brlogger | Meeting started Thu May 23 09:00:02 2019 UTC and is due to finish in 60 minutes. The chair is szlin. Information about MeetBot at http://wiki.debian.org/MeetBot. | 09:00 |
| brlogger | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 09:00 |
| brlogger | The meeting name has been set to 'cip_irc_weekly_meeting' | 09:00 |
| *** brlogger changes topic to " (Meeting topic: CIP IRC weekly meeting)" | 09:00 | |
| szlin | #topic rollcall | 09:00 |
| *** brlogger changes topic to "rollcall (Meeting topic: CIP IRC weekly meeting)" | 09:00 | |
| szlin | please say hi if you're here | 09:00 |
| pave1 | hi | 09:00 |
| vidda | hi | 09:00 |
| iwamatsu | hi | 09:00 |
| patersonc | hi | 09:00 |
| szlin | #topic AI review | 09:00 |
| *** brlogger changes topic to "AI review (Meeting topic: CIP IRC weekly meeting)" | 09:00 | |
| szlin | 1. Upload check script to lts-commit-list repository - Pavel | 09:00 |
| pave1 | I've just issued the command to do the upload :-). | 09:01 |
| szlin | #info https://gitlab.com/cip-project/cip-kernel/lts-commit-list/commit/820135ffab6611345d2fcc828959b657fcdc049d | 09:01 |
| szlin | pave1: thank you | 09:01 |
| pave1 | It is there now, but it will need more work. So far it is more of a python library that needs to be called from python. | 09:01 |
| bwh | hi | 09:01 |
| szlin | 2. Release 4.4 and 4.19 kernel - Iwamatsu | 09:02 |
| szlin | #info https://lists.cip-project.org/pipermail/cip-dev/2019-May/002369.html | 09:02 |
| szlin | 3. Prepare the CIP kernel release document - Iwamatsu | 09:02 |
| szlin | iwamatsu: would you like to update this AI? | 09:03 |
| iwamatsu | We released 4.19.13-cip2 and 4.4.176-cip32. | 09:04 |
| szlin | iwamatsu: thanks, but this topic related to the release document of CIP kernel | 09:05 |
| iwamatsu | I wrote a brief explanation in the email. Do we need more explanation? | 09:05 |
| szlin | IIRC, pavel requested to have release procedure for CIP kernel | 09:06 |
| szlin | pave1: please correct me if I'm wrong | 09:07 |
| pave1 | Correct. If you point me what email it is, I guess I can take a look and transform it into README somewhere. | 09:07 |
| iwamatsu | I see. | 09:09 |
| iwamatsu | Please give me some time. | 09:09 |
| szlin | iwamatsu: thanks, I will keep this AI | 09:09 |
| szlin | 4. Arrange a meeting between CIP core and CIP security WG - szlin | 09:09 |
| szlin | -> Done | 09:09 |
| szlin | #topic Kernel maintenance updates | 09:09 |
| *** brlogger changes topic to "Kernel maintenance updates (Meeting topic: CIP IRC weekly meeting)" | 09:09 | |
| szlin | Iwamatsu-san released kernel 4.19.13-cip2 and 4.4.176-cip32 | 09:09 |
| szlin | #info https://lists.cip-project.org/pipermail/cip-dev/2019-May/002369.html | 09:09 |
| szlin | iwamatsu: pave1 would you like to update the status of kernel maintenance? | 09:10 |
| pave1 | szlin: I did review 4.19.38 and 4.19.45. Nothing much else to report. | 09:10 |
| szlin | pave1: thank you for your update | 09:11 |
| szlin | any other topics? | 09:12 |
| iwamatsu | szlin: I reviewed the released kernel patch (4.4.157). | 09:12 |
| szlin | iwamatsu: thank you. | 09:12 |
| iwamatsu | And I restart failed-patches tracking. | 09:13 |
| iwamatsu | I create new repository for this, and pushed. https://gitlab.com/cip-project/cip-kernel/classify-failed-patches | 09:13 |
| szlin | #info https://gitlab.com/cip-project/cip-kernel/classify-failed-patches | 09:13 |
| iwamatsu | This is based on a script created by Daniel. There are still many problems. | 09:14 |
| szlin | iwamatsu: I suggest it would be better to have license declaration | 09:15 |
| iwamatsu | szlin: OK, I will add license file | 09:15 |
| szlin | iwamatsu: thanks | 09:15 |
| pave1 | iwamatsu: Let me take a look. I wonder if it would make sense to have single repository for lts commit lists etc... | 09:16 |
| szlin | #action Add license file in classify-failed-patches | 09:16 |
| szlin | pave1: fair enough | 09:16 |
| szlin | any other topics? | 09:16 |
| pave1 | iwamatsu: And I guess we should find better way to reference patches than their sumary line. | 09:16 |
| pave1 | iwamatsu: But we'll probably not solve that now over irc. | 09:17 |
| bwh | You should usse the first 12 digits of the commit hash too | 09:17 |
| iwamatsu | pave1: Indeed. | 09:18 |
| pave1 | bwh: Commit hash of the upstream commit, agreed. | 09:18 |
| szlin | #agreed Use commit hash instead of summary line in "failed patches" | 09:19 |
| szlin | 3 | 09:19 |
| szlin | 2 | 09:19 |
| szlin | 1 | 09:19 |
| szlin | #topic Kernel testing | 09:19 |
| *** brlogger changes topic to "Kernel testing (Meeting topic: CIP IRC weekly meeting)" | 09:19 | |
| patersonc | Three topics from me today. | 09:19 |
| patersonc | 1) | 09:20 |
| patersonc | The stability of lab-cip-renesas has improved since we switched out a dodgy remote power switch. | 09:20 |
| patersonc | 2) | 09:20 |
| patersonc | #info: Michael (Siemens) has released gitlab-cloud-ci. A tool which makes it possible to setup a Kubernetes cluster in an AWS instance, driven by GitLabCI. | 09:20 |
| patersonc | #info https://gitlab.com/cip-playground/gitlab-cloud-ci | 09:20 |
| patersonc | Looks like a good tool for us, however I wonder how much AWS would end up costing. | 09:20 |
| patersonc | I don't know how good GitLab's shared (free) runners are, so have started looking into GitLab CI in more detail to test. | 09:20 |
| patersonc | Let me know if anyone has any experience/thoughts. | 09:20 |
| patersonc | It looks like Daniel has taken a quick look. | 09:21 |
| szlin | patersonc: are you using gitlab ce or gitlab ee? | 09:21 |
| patersonc | szlin: Whatever CIP's LAVA account is | 09:22 |
| szlin | patersonc: got it, thanks. | 09:22 |
| bwh | pave1: I understand that running CI "in the cloud" is usually rather expensive | 09:22 |
| szlin | any other topics? | 09:22 |
| bwh | I mean patersonc ^ | 09:22 |
| patersonc | s/LAVA/GitLab | 09:22 |
| patersonc | bwh: That's my worry. As Daniel suggested we could trial it. There is probably a tool in AWS to estimate though. | 09:22 |
| patersonc | For things that aren't updated much, perhaps the free runners would be good enough. | 09:23 |
| pave1 | patersonc: Or maybe try gitlab's shared runners, first, and see how it works? | 09:23 |
| patersonc | pave1: That's what I started looking into last night | 09:23 |
| patersonc | The alternative is a member company shares a server for the GitLab runner | 09:24 |
| patersonc | Any more comments? Or should I move on? (1 more topic) | 09:25 |
| szlin | let's move on | 09:25 |
| patersonc | 3) | 09:25 |
| patersonc | It looks like it is going to be hard for all member companies to set up their own LAVA worker for their reference platforms, | 09:25 |
| patersonc | so I am investigating setting up/getting some quotes for a new external LAVA worker to host all CIP reference platforms. | 09:26 |
| patersonc | This means that members can just send boards to a central place to be added to a lab. | 09:26 |
| patersonc | Does anyone have any specific requirements for this new lab? | 09:26 |
| patersonc | One thing I'm not sure on is what kind of uptime guarantees we need. For example, are we happy for a lab to be down for a few hours? A day? ... | 09:26 |
| patersonc | The other is bandwidth requirements | 09:26 |
| patersonc | Any thoughts? | 09:27 |
| szlin | patersonc: I suggest you can send the investigating email to cip-dev | 09:27 |
| patersonc | szlin: Sure | 09:27 |
| pave1 | We are releasing kernels two times a month. So I guess downtime of few hours should not be huge problem for us. | 09:28 |
| pave1 | Bandwidth: It seems that LAVA does a lot of "lets grab this filesystem image from this url and apply it". | 09:28 |
| patersonc | Thanks pave1 . Let's continue this discussion after the meeting. | 09:29 |
| pave1 | that is going to eat some bandwidth, and maybe we should have images close to the lab.. | 09:29 |
| pave1 | patersonc: ack. | 09:29 |
| szlin | #action send investigating email for kernel-testing lab to cip-dev - patersonc | 09:29 |
| szlin | any other topics? | 09:29 |
| patersonc | Not from me | 09:29 |
| szlin | 3 | 09:29 |
| szlin | 2 | 09:29 |
| szlin | 1 | 09:29 |
| szlin | #topic CIP Core | 09:29 |
| *** brlogger changes topic to "CIP Core (Meeting topic: CIP IRC weekly meeting)" | 09:29 | |
| szlin | any topics? | 09:30 |
| szlin | 3 | 09:30 |
| szlin | 2 | 09:30 |
| szlin | 1 | 09:30 |
| szlin | #topic Software update | 09:30 |
| *** brlogger changes topic to "Software update (Meeting topic: CIP IRC weekly meeting)" | 09:30 | |
| szlin | iwamatsu: I saw you sent the ITP email with libuboot* | 09:31 |
| szlin | iwamatsu: and "libubootenv" was uploaded a week ago | 09:32 |
| szlin | any other topics? | 09:32 |
| szlin | 3 | 09:32 |
| szlin | 2 | 09:32 |
| szlin | 1 | 09:32 |
| iwamatsu | szlin: Yes, I did. | 09:32 |
| szlin | iwamatsu: thanks | 09:32 |
| szlin | #topic AOB | 09:32 |
| *** brlogger changes topic to "AOB (Meeting topic: CIP IRC weekly meeting)" | 09:32 | |
| szlin | any other business? | 09:33 |
| szlin | 3 | 09:33 |
| szlin | 2 | 09:33 |
| szlin | 1 | 09:33 |
| szlin | #endmeeting | 09:33 |
| brlogger | Meeting ended Thu May 23 09:33:14 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:33 |
| brlogger | Minutes: https://irclogs.baserock.org/meetings/cip/2019/05/cip.2019-05-23-09.00.html | 09:33 |
| brlogger | Minutes (text): https://irclogs.baserock.org/meetings/cip/2019/05/cip.2019-05-23-09.00.txt | 09:33 |
| brlogger | Log: https://irclogs.baserock.org/meetings/cip/2019/05/cip.2019-05-23-09.00.log.html | 09:33 |
| *** brlogger changes topic to "Civil Infrastructure Platform Project. Find the logs at https://irclogs.baserock.org/cip/" | 09:33 | |
| szlin | thank you all | 09:33 |
| pave1 | Thank you! | 09:33 |
| iwamatsu | thank you | 09:33 |
| patersonc | thanks | 09:33 |
| patersonc | pave1: Uptime: I agree we can live with the outages for a bit. Do you think we can stretch to 12 or 24 hours? Or would that cause havoc? | 09:34 |
| patersonc | Fingers crossed we'd still have the lab at Renesas | 09:34 |
| pave1 | patersonc: I guess even 24 hours is okay from my point of view as long as lab is more up than down :-). | 09:35 |
| patersonc | Indeed. If it's 24 hours down every week then that's not good ;) | 09:35 |
| pave1 | I mean, we agreed to try to release kernels at given days, but... | 09:36 |
| pave1 | ...these are stable kernels, they are not really moving quickly (and they should not be). | 09:36 |
| patersonc | I'm reticent to say something like 99.9% uptime though. I hate that phrase ;) | 09:36 |
| pave1 | ...if we can't test we delay... | 09:36 |
| patersonc | I guess we can get various estimates and see what we can afford. | 09:37 |
| pave1 | Actually... | 09:37 |
| pave1 | If we can afford more testing, I'd rather spend it on testing upstream "when we can" | 09:37 |
| pave1 | rather than guaranteed-testing-cip-kernel-within-hours. | 09:38 |
| patersonc | Do you mean running our tests on mainline? | 09:38 |
| patersonc | I don't think this would add much cost, as most of the time our infrastructure will be idle anyway. | 09:39 |
| pave1 | If we can catch bug in -next... it saves a lot of work for everyone. If we can catch bug in mainline, we are still not affected. If we can catch bug in -stable... it is still better than catching it in -cip :-). | 09:39 |
| patersonc | Agreed | 09:39 |
| * patersonc needs to get CI setup... | 09:40 | |
| pave1 | patersonc: It is mostly human cost, yes... boards are expected to be mostly idle. | 09:40 |
| patersonc | Another option as well is to allow KernelCI to submit jobs to our lab(s). | 09:41 |
| pave1 | patersonc: Problem may be that all boards may not be able to run all the branches. Mainline, -next and -cip should work, but -stable may not have the neccessary hardware support. | 09:41 |
| pave1 | patersonc: I'm not familiar with KernelCI. | 09:41 |
| patersonc | True, but we can filter what boards are tested with what. | 09:42 |
| patersonc | KernelCI mainly run boot tests on 100's boards every commit upstream, on lots of branches. | 09:42 |
| pave1 | patersonc: But I guess there are other items on my wishlist than "testing infrastructure is available 24/7" :-). | 09:42 |
| patersonc | They also run some DRM/V4L2 tests, but hope to expand | 09:42 |
| pave1 | patersonc: I guess boot testing would be quite useful for us. | 09:43 |
| patersonc | We'd also be doing the same of course if we start testing mainline/next ourselves | 09:44 |
| patersonc | But KernelCI is a good place for collecting all of the results | 09:45 |
| patersonc | https://kernelci.org/boot/ | 09:45 |
| pave1 | I'm not sure how much work is it to "test each mainline commit" vs. "test -next and -mainline daily". | 09:45 |
| patersonc | Good point | 09:45 |
| patersonc | Maybe KernelCI doesn't test every commit, I'm not 100% sure | 09:46 |
| pave1 | Daily testing would be adequate from my point of view. | 09:46 |
| patersonc | Sure | 09:46 |
| pave1 | ...but keeping test farm busy for a while with test would be nice test of the farm, and of stability of those boards, so may be worth doing too :-). | 09:46 |
| patersonc | True | 09:47 |
| patersonc | We'd have to get the CI build side of things sorted though ;) | 09:47 |
| patersonc | Regarding bandwidth, it is possible to use a cache, which will reduce bandwidth for static images. I just haven't got round to trying yet | 09:47 |
| pave1 | Maybe bandwidth is not really a problem. The boards are not that fast and you probably have faster than 100mbit line to the internet... | 09:48 |
| patersonc | pave1: You'd be surprised ;) Still, for the new lab bandwidth requirements are something the provider would need to know | 09:49 |
| pave1 | Looking at the kernelci stuff... Yes, that looks quite nice. | 09:50 |
| pave1 | Ok, so lets say... There's 10 boards in the lab, each test takes 5 minutes and needs to download 100MB image . | 09:51 |
| patersonc | They are about to setup a LF project, which CIP may join | 09:51 |
| patersonc | Is 100MB enough? Arm64 defconfig modules are 200MB on their own | 09:52 |
| patersonc | I'm not sure what x86 images are like | 09:53 |
| pave1 | Hmm. | 09:53 |
| pave1 | If I assume 100MB image, that is 33mbit AFAICT. | 09:55 |
| pave1 | With 1GB images, that would be 300mbits. | 09:56 |
| pave1 | At some point local caching and rsync (and similar) tricks start to make sense. | 09:56 |
| patersonc | Yep | 09:56 |
| pave1 | But I thought existing tests were smaller than "all defconfig modules". | 09:57 |
| patersonc | Probably. That's a worst case I think | 09:58 |
| patersonc | It depends on what configs we plan to test | 09:58 |
| pave1 | We may do bigger test once in a while, but normally testing modules that can't be inserted on target system makes little sense. | 09:59 |
| iwamatsu | I am sorry if I'm wrong. | 09:59 |
| iwamatsu | Can we not store kernel data etc in local storage?\ | 09:59 |
| patersonc | Indeed. And boot testing probably doesn't need any | 09:59 |
| patersonc | iwamatsu: There is a way to do this, but it would take some coordination between the different labs as they'd all have to have the exact same setup/versions. | 10:00 |
| patersonc | You never know where a job will end up. | 10:00 |
| patersonc | But anyway, with caching enabled the only thing that will need to be updated often is probably the Kernel image being tested. | 10:01 |
| pave1 | ..and that should be <10MB. So 3mbit line ;-). | 10:02 |
| iwamatsu | I see. | 10:02 |
| pave1 | Hmm. If we are thinking about kernelCI, perhaps asking people already running kernelCI instances for their bandwidth (and other) requirements makes sense? | 10:04 |
| patersonc | Yep. Already on it :) | 10:09 |
| pave1 | (y) | 10:09 |
| pave1 | iwamatsu: are you around? | 10:30 |
| *** vidda has quit IRC | 10:44 | |
| toscalix | patersonc: storage server with Gb link to the lab and cache for the most common remote images/branches to test. I have seen this approach before ;-) | 12:55 |
| patersonc | :) | 12:55 |
| *** toscalix has quit IRC | 12:57 | |
| pave1 | see you... | 12:57 |
| *** pave1 has quit IRC | 12:57 | |
| *** alicef has quit IRC | 20:52 | |
| *** alicef has joined #cip | 21:43 | |
| *** rajm has quit IRC | 21:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!