16:00:21 <dcavalca> #startmeeting Hyperscale SIG
16:00:21 <centbot> Meeting started Wed Oct 27 16:00:21 2021 UTC.  The chair is dcavalca. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:21 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:27 <dcavalca> #chair dcavalca jvreeland
16:00:27 <centbot> Current chairs: dcavalca jvreeland
16:00:36 <dcavalca> good morning everyone
16:00:40 <anitazha> morning!
16:02:08 <dcavalca> let's get started
16:02:13 <dcavalca> #topic Followups
16:02:26 <dcavalca> anybody has followups to discuss?
16:02:48 * dcavalca still hasn't had time to poke at the openssl 3.0 stuff unfortunately
16:03:25 <arrfab> dcavalca: just one thing about centos-infra ticket 307 (secureboot request)
16:03:39 <arrfab> we (centos infra team) will probably have to close it
16:03:58 <Eighth_Doctor> hey
16:03:59 <arrfab> and just ask to resubmit to cpe team eventually, as it seems there is no follow-up
16:04:16 <dcavalca> arrfab: is there anything you need from our end there?
16:04:31 <Eighth_Doctor> but they're both CPE?
16:04:38 <arrfab> Eighth_Doctor: yes and no
16:05:01 <arrfab> if that's a just a request  landing in our tracker, and that we don't get help/answers, nothing we can do (at infra and releng level)
16:05:33 <arrfab> so resubmit as cpe initiative, so that it's then forcing a discussion with stakeholders, including Bex, and have a no/nogo
16:05:45 <arrfab> and then only coming back to us with some resources, plan, etc
16:05:54 <dcavalca> arrfab: iirc bex was on the ticket and wasn't opposed to it
16:06:14 <arrfab> he's on internal doc that I shared but nothing else .. so we can keep waiting for official statement
16:06:40 <dcavalca> arrfab: if you're waiting on bex I'll just go bug him, that's easy to do :)
16:06:45 <arrfab> dcavalca: ask the official RH liaison between project and RH legal ?
16:06:54 <arrfab> yeah, what I was suggesting ;-)
16:07:09 <dcavalca> yeah, happy to do that
16:07:26 <arrfab> but I think that it will be anyway "no way that we'll allow to sign with the distro key"
16:07:51 <arrfab> and infra and releng alone doesn't want to start working without perm on a complex setup that :
16:08:01 <arrfab> - has zero value for centos (stream)
16:08:09 <arrfab> - would need hardware (and budget) that we don't have
16:08:30 <dcavalca> I can help with hardware if needed fwiw
16:08:41 <arrfab> dedicated hsm ?
16:08:52 <arrfab> and even that doesn't solve anything
16:09:02 <themayor> hey hey
16:09:03 <arrfab> going the full route of secureboot is loooooong
16:09:18 <arrfab> been there, done that
16:09:32 <arrfab> because you'll have to maintain/rebuild the whole stack
16:09:33 <dcavalca> if there's specific equipment that would help the project, I'm happy to make the case with fb that we should sponsor it, and I'm fairly confident that wouldn't be an issue from our end
16:09:41 <dcavalca> but yeah, I agree we need to sort out the whole thing first
16:09:43 <arrfab> and that one will not be compatible for kmods sig , etc
16:10:39 <arrfab> anyway, I proposed options , so just ask Bex if he can get answer on my proposal and then we can review, based on answer
16:11:07 <bkircher> hi
16:11:10 <dcavalca> sounds good
16:11:15 <dcavalca> thanks for letting us know arrfab
16:11:22 <dcavalca> I'll follow up with bex and prod him for an answer
16:11:31 <arrfab> going through rhboot issue tracker on github and waiting for someone to just eventually review (after several weeks/months) it (just for shim) is problematic
16:11:52 <themayor> yes its a very long process
16:12:02 <arrfab> I heard that some projects bypassed what was normally a requirement, but all shim should have been accepted there
16:12:21 <arrfab> themayor: let me look if you followed that process, or just had direct contact with Microsoft :)
16:13:03 <arrfab> https://github.com/rhboot/shim-review/issues?q=is%3Aissue+is%3Aclosed
16:13:44 <arrfab> https://github.com/rhboot/shim-review/issues/152
16:14:09 <arrfab> that was *really* fast ... myself for centos 7 I had to wait *months* in the past :/
16:14:19 <arrfab> anyway, OT for hyperscale SIG, sorry :)
16:15:07 <dcavalca> arrfab: we care about this stuff, so it's definitely in scope for the meeting :)
16:15:22 <dcavalca> anything else for followups?
16:16:05 <dcavalca> alright, time for
16:16:06 <dcavalca> #topic Announcements
16:16:25 <dcavalca> #info resctl-demo and resctl-bench now available for EPEL: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e713d25c47
16:16:41 <dcavalca> this is relevant here as a lot of the fun resctl stuff relies on having a modern kernel
16:16:49 <dcavalca> so I think this could make for a nice showcase of Hyperscale
16:17:19 <dcavalca> (also relies on btrfs, of course)
16:18:03 <dcavalca> my only other announcement is that I'm working on updating the zstd and lz4 packages with some upstream help (which happens to also work at fb)
16:18:18 <dcavalca> these packages are ABI/API compatible so we should be able to do this without rebuilding the world
16:19:14 <dcavalca> anybody else has announcements to share?
16:19:28 <Eighth_Doctor> are these updates in Fedora yet?
16:19:31 <Eighth_Doctor> or in CS9?
16:19:41 <dcavalca> Eighth_Doctor: yes, and yes
16:19:53 <Eighth_Doctor> even zstd 1.5?
16:20:08 <Eighth_Doctor> huh so it is
16:20:09 <dcavalca> pretty sure, lemme double check
16:20:35 <dcavalca> yep both fedora and c9s are at zstd 1.5.0
16:20:50 <dcavalca> my plan was actually to just import the Fedora package in Hyperscale to make things easy
16:21:03 <Eighth_Doctor> sounds good
16:21:06 <dcavalca> I did a local build yesterday and all tests were passing, so it should be fine
16:21:12 <Eighth_Doctor> nice
16:21:28 <dcavalca> (as an aside, the testsuite for this thing is pretty impressive, I wish all projects were like that)
16:21:42 <Eighth_Doctor> don't forget to create tags for these packages in the package-bugs tracker
16:21:57 <dcavalca> will do, thanks for the reminder
16:22:18 <dcavalca> I should probably write up a "how to add a new package to the sig" checklist in the documentation
16:22:28 <Eighth_Doctor> yup
16:23:17 <bkircher> uh, that would be nice
16:23:53 <dcavalca> I'll try to put something together as I work on these
16:24:09 <dcavalca> anything else for announcements?
16:25:11 <dcavalca> alright, let's move to
16:25:14 <dcavalca> #topic Tickets
16:25:57 <dcavalca> jvreeland: built some new kernels for #7 yesterday
16:26:11 <dcavalca> though we can't tag the c9s one yet as the tags aren't open
16:26:19 <dcavalca> bkircher: any update on the qemu stuff for #67 ?
16:26:41 <bkircher> yes, actually started working on it today 😅
16:26:49 <dcavalca> awesome
16:26:50 <bkircher> I have a 6.0 src.rpm that looks OK
16:26:58 <bkircher> 6.1 fails due to some minor rpm macro thing
16:27:16 <bkircher> amd I still have no idea how to test against conflicting binaries in RHEL
16:27:21 <bkircher> but yeah, I started
16:28:35 <dcavalca> bkircher: for the conflicting binaries, I think you can use repoquery to see the list of the ones provided by the existing packages
16:28:49 <bkircher> yes
16:28:55 <dcavalca> most should be fine thanks to the qemu-kvm naming, but a few will definitely need manual handling
16:30:30 <bkircher> hmm, yeah, wonder if there is another package that had this problem and how it was solved
16:31:24 <dcavalca> if it's just binaries, I think renaming them in %install is probably fine
16:31:42 <bkircher> OK
16:31:42 <dcavalca> if it's libraries, or binaries that get called by other binaries and whose name is hardcoded in the source, that'll be harder
16:32:24 <dcavalca> I also spent some time going over open new-package tickets
16:32:33 <Eighth_Doctor> qemu doesn't produce libraries, iirc
16:32:39 <Eighth_Doctor> so it should be relatively easy
16:32:39 <dcavalca> for #64 (socat), we're waiting on an upstream release, which I'm told should come near the end of the month
16:33:05 <dcavalca> for #65 (linuxptp), I have the time folks on my end working to get their patches cleaned up for upstreaming
16:33:41 <Eighth_Doctor> nice
16:34:11 <dcavalca> anything else for tickets?
16:34:49 <bkircher> just a question here about that libiscsi-devel package in cs9
16:35:05 <bkircher> https://bugzilla.redhat.com/show_bug.cgi?id=2004762
16:35:29 <dcavalca> looks like that's been passed around within RH
16:35:39 <dcavalca> I suspect there's a bunch of private comments on it we can't see
16:36:04 <bkircher> ah OK
16:36:24 <bkircher> because the change looks rather simple to me
16:36:35 <dcavalca> the jira issue is also private so I can't see that either
16:36:44 <bkircher> OK I guess then we wait
16:36:58 <dcavalca> yeah the change itself is trivial, but it has some support implications for them, so I assume they're trying to figure that out
16:37:13 <bkircher> OK
16:37:44 <Eighth_Doctor> hopefully that gets resolved soon
16:38:14 <dcavalca> I'll make a note to bring this up in the EPEL meeting this afternoon, as it's actively blocking an effort to get qemu packaged in EPEL
16:39:09 <Eighth_Doctor> KDE Plasma for CS9 is partly blocked on https://bugzilla.redhat.com/show_bug.cgi?id=2009831 as well
16:40:32 <dcavalca> thanks, I'll bubble up that one too
16:40:54 <dcavalca> I think that's all for tickets today
16:40:58 <dcavalca> #topic Membership
16:41:11 <dcavalca> I don't think we have anything here this week?
16:42:01 <dcavalca> #topic Misc
16:42:05 <themayor> no other than i would like to join and thats in progress
16:42:10 <themayor> need to file the ticket
16:42:29 <dcavalca> themayor: sure thing, yeah feel free to file a ticket
16:42:35 <dcavalca> anything in particular you're interested in working on?
16:45:24 <themayor> I guess as things pop up, yes and I want to work on making sure AlmaLinux is working towards hyperscale compatibility which will require work on our end on a few things
16:45:59 <dcavalca> sounds good
16:46:43 <Eighth_Doctor> it might be nice if the elevate tool Alma has could take btrfs c6/c7/ol systems and bring them to hyperscale variant systems
16:47:01 <dcavalca> oh that would be cool
16:47:02 <Eighth_Doctor> once we have the kernel thing sorted out
16:47:21 <themayor> yes, thats a great idea and something we spoke about being able to do
16:47:41 <Eighth_Doctor> for context: https://almalinux.org/elevate
16:47:51 <themayor> not just hyperscale variants, but other variants as well
16:48:46 <dcavalca> oh I hadn't realized this was using leapp under the hood
16:49:20 <dcavalca> that's great, really glad you were able to build it on top of existing tooling
16:49:34 <themayor> yes its a combination of leapp plus a service to enable contributions of metadata and customization of metadata
16:50:04 <themayor> yup, and we're in contact with the leapp team and bex to make sure anything that needs to be upstream gets there
16:50:21 <dcavalca> y'all should do a blog post on this if you haven't already
16:50:28 <dcavalca> on the collaboration angle of it I mean
16:54:29 <themayor> its in the works
17:01:17 <dcavalca> I think that's it for today, thanks everyone for joining
17:01:24 <dcavalca> #endmeeting