15:00:03 <pjgeorg> #startmeeting Kmods SIG
15:00:03 <centbot> Meeting started Mon Oct 18 15:00:03 2021 UTC.  The chair is pjgeorg. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:03 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:13 <pjgeorg> #chair pjgeorg billings
15:00:13 <centbot> Current chairs: billings pjgeorg
15:00:22 <billings> Good day
15:00:31 <pjgeorg> Hi
15:00:35 <arrfab> morning guys (just lurking while working on other things)
15:02:01 <pjgeorg> What topics are currently open and shall be discussed here?
15:02:46 <billings> Looks like #15 User-facing documentation
15:03:06 <billings> Maybe a section of the Wiki?
15:03:21 <billings> https://pagure.io/centos-sig-kmods/sig/issue/15 is what I'm talking about
15:03:37 <pjgeorg> I prefer using the new sigs.centos.org
15:03:54 <billings> that would be great, I should figure out how that is managed
15:04:32 <arrfab> just a git repo with some .md and a mkdocs.yml file, then a request through tracker and it will be appearing on sigs.c.o :)
15:05:00 <billings> arrfab: is there a reference I could look at?
15:05:21 <arrfab> https://www.mkdocs.org/
15:05:29 <arrfab> for how to structure doc/mkdocs.yml
15:05:42 <billings> I mean... for example, the git repo for the hyperscal SIG's docs
15:05:45 <arrfab> https://git.centos.org/centos/centos-infra-docs
15:05:49 <billings> or that
15:06:05 <arrfab> one option is to link to git repo itself
15:06:17 <arrfab> which I think that hyperscale is doing too
15:06:46 <arrfab> yep https://sigs.centos.org/hyperscale/ has the link on top/right to the git repo used
15:06:58 <arrfab> same for automotive sig, who also has its namespace there
15:08:01 <billings> ok.  I'll take a look at getting some documentation
15:08:16 <billings> pjgeorg: do you have any problems with me putting the docs in the sig repo where the issues live?
15:08:47 <pjgeorg> Great. No. I think we even once agreed to put it there.
15:09:01 <pjgeorg> Also see a (very old) PR by myself for some internal doc: https://pagure.io/centos-sig-kmods/sig/pull-request/8
15:09:42 <billings> Cool.  I'll take that issue and add the content of #8 to a page
15:09:47 <billings> that way we can have a landing page
15:10:09 <pjgeorg> #action billings Work on documentation
15:10:25 <billings> I wonder if we can turn some of the stats from the talk into a page with pretty charts
15:10:45 <pjgeorg> That something I can look into.
15:11:05 <pjgeorg> Just to make sure: Talking about kABI breakage?
15:11:09 <billings> yes
15:11:27 <pjgeorg> I'll look into it. I also want to continue this stats for future kernel releases
15:11:50 <billings> if we get any kind of build automation, we might want to get some pass/fail badges on the page too
15:11:59 <pjgeorg> #action pjgeorg Create pretty kABI breakage charts
15:12:43 <pjgeorg> Don't know how complicated that will be.
15:13:08 <pjgeorg> I first wanted to get the automation on some public machine (currently running on my PC for selected packages).
15:14:16 <pjgeorg> My idea was to use CentOS CI infrastructure for that. But I haven'T had time yet to look into it.
15:15:20 <billings> *nod* I was just thinking a dashboard for people to easily find what kmods we offered and the current status
15:16:21 <pjgeorg> Yes good idea. In the first version it might be sufficient to just list which version (c8, c8s, c9s) we (try to) provide the package for.
15:18:04 <pjgeorg> Which reminds me of another question. Knowing that kernel module signing will not be available any time soon (if at all):
15:18:22 <pjgeorg> Do we want to tag packages as -release without signing the modules?
15:19:12 <billings> I think we're probably going to be stuck doing so.  I'll add "turn off secure boot" as another thing we need to document
15:19:58 <pjgeorg> Ok, so we agreed to release anyway.
15:20:57 <pjgeorg> #agreed Release packages with non-signed kmods (for now)
15:21:29 <arrfab> yeah, no answer for secureboot question internally so I wouldn't count on it at this stage
15:23:35 <billings> being a RH employee means I *can* look at some of these discussions, but I choose not to so I can keep my CentOS hat on here
15:26:57 <pjgeorg> This also reminds me of the DD issue. There has been an answer by upstream concerning to the RFE I filled: https://pagure.io/koji/issue/2998
15:29:08 <billings> so, no real solution
15:29:10 <pjgeorg> In https://pagure.io/centos-infra/issue/418 arrfab mentioned alternative solutions. I try to get back to this issue soon (depending on time constraints).
15:31:03 <arrfab> pjgeorg: yeah, basically we can abuse koji tagging or just a simple message payload posted on mqtt topic (restricted by ACL) that would trigger a job to build the dd and push it out
15:34:40 <pjgeorg> I have to admit that I do not get 100% what you mean, but if you tell me this is an option. I'll need to learn what infrastructure/services are currently available and how to use it/them :)
15:35:46 <arrfab> oh, message bus (mqtt broker) is there already but we'd just need to plumb a service at the other side to react to messages posted to a topic and so just build the dd iso
15:35:49 <billings> I assume arrfab means we'd have the process that builds it live in some other infrastructure
15:35:56 <billings> and it would use mqtt to talk to koji
15:36:09 <billings> (and vice versa)
15:36:40 <pjgeorg> I think I now get it better. All this stuff is still new to me.
15:36:46 <billings> same here
15:37:15 <billings> the reason why we use koji is so the assets appear in the centos mirrors, right?
15:37:22 <pjgeorg> Can the other side reacting to the messages be on some CentOS infrastructure?
15:37:58 <arrfab> pjgeorg: yes, it has to : all that should appear on mirror network would have to be built on centos infra/buildsystem
15:38:34 <pjgeorg> Ok, that sounds good to me. Thanks.
15:38:53 * arrfab didn't even know that billings is a colleague ... TIL
15:39:01 * billings waves
15:39:06 <billings> its relatively new.
15:39:14 <arrfab> I see that now :)
15:39:53 <billings> BTW I'd be happy to volunteer time for more internal centos-ey stuff if you need it
15:40:23 <billings> I work in Endpoint systems so my view is largely outside of the infrastructure
15:40:44 <billings> but if I can do anything to get kmods stuff going, I'd be glad to help
15:41:34 <billings> pjgeorg: basically, I support the RHEL desktop systems (and laptop) for RH employees
15:42:34 <pjgeorg> arrfab: I'll comment in https://pagure.io/centos-infra/issue/418 later to get this moving forward. But I do not have much time on my side to work on it atm, so no rush.
15:43:24 <billings> I deleted the kmod-e1000 module, since it looks like it'll be upstream
15:43:33 <billings> do we have any good candidates for -release?
15:43:39 <pjgeorg> billings: Good to know. I plan to switch my Laptop from Fedora to CentOS Stream 9 after EPEL 9 is available.
15:44:17 <pjgeorg> I guess everything in packages-rebuild once a new kernel has been release and I converted them to kABI tracking.
15:44:26 <arrfab> billings: yeah, I confirm it landed in stream 9 kernel (already using it on older infra used for ci), reason why I closed rfe ticket for kmods sig
15:45:32 <pjgeorg> The wireguard package is also a good candidate.
15:46:18 <billings> I need to get the kafs-utils packages working in either EPEL or the Storage SIG before I can promote the kmod-kafs package
15:47:12 <billings> same with the yet unpackaged ksmbd driver
15:48:06 <pjgeorg> Reminds me that I should rebase my ntfs3 code to the current 5.15-rc
15:49:11 <pjgeorg> And we do not have repositories for kmod-ksmbd and kmod-ntfs3 on git.centos.org yet.
15:51:20 <billings> right
15:51:52 <pjgeorg> Are you missing any other package there?
15:54:00 <billings> just kmod-ksmbd
15:56:55 <pjgeorg> Ok, I'll request both.
15:57:48 <pjgeorg> Anything else for today?
15:59:55 <pjgeorg> Seems like nothing else to discuss. I'll close the meeting. Thanks for attending!
16:00:28 <pjgeorg> #endmeeting