Meeting started at 2026-02-11 16:08:17 UTC

The Meeting name is 'CentOS Hyperscale SIG'

!hi

Davide Cavalca (dcavalca) - he / him / his

!hi

Gabriele Mambrini (gmambro) - he / him / his

!hi

!hi

Nik Nikovsky (niknikovsky) - he / him / his

Pawel Zmarzly (pawo2500) - he / him / his

!hi

Neal Gompa (ngompa) - he / him / his

let's get started

talks from Connect should be published already

!hi

and I need to clean up and publish the meetup notes as well

Raymond Colebaugh (rcolebaugh) - he / him / his

I assume that refers to One Connect Hub in Albania?

CentOS Connect in Brussels, before FOSDEM

Ah

as discussed there, I'm going to file a ticket with infra to get draft builds turned on in CBS

so we can start experimenting with them in our CI flows

it'd be nice to use them for packaging updates

particularly when I try to do kernel package updates

https://gitlab.com/CentOS/infra/tracker/-/issues/1853

anything else for followups?

next up

a bunch of us will be at SCALE next month

and there's a fedora/centos event on Fri

Yep, I'll be there

!hi

Neal Gompa (ngompa) - he / him / his

also as discussed during the meetup, pzmarzly and I have migrated all our repos from pagure to gitlab

please eyeball for anything that might look off there

I haven't had a chance to look too deeply, but things look mostly fine

a reminder though that some of us may have created projects out of our pagure namespace that actually belong in our gitlab one

yeah I still need to figure out some of my personal ones

!hi

Michel Lind (salimma) - he / him / his

totally forgot about this, sorry

anything else for announcements?

I'll be doing a rebase to 6.18 today

I might even get c9s working thanks to a tip from Peter Georg

oh I guess we should talk about the btrfs thing

the whole thing makes me want to burn the ARK spec to the ground 🔥

for those who might have missed it: gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/2009

ARK is the reason I have not upstreamed the perf improvements we made

there is a corresponding ARK MR too

did they file the ARK MR for this?

ah perfect thanks

so there are upsides and downsides to this

I will need to adapt when this lands in ARK because as it stands, this will break btrfs support for us since it is incompatible with how we enable it

wait, how ?

is it not just "enable the btrfs module"?

it's enabled as a module and that module is shunted to kernel-modules-internal

we want it in kernel-modules-core when it's built as a module

ahh

that's how they don't ship it

we actually enable it as a built-in filesystem for Hyperscale to side-step that whole mess

I didn't want to touch the variants stuff, and now I will have to anyway

um.. are internal modules shipped but somehow barred from being used by the host kernel? e.g. excluded from dracut

hilariously fs/bcachefs is set for modules-core :/

my understanding is that the package is filtered out, it's simply not available

otherwise it's an ordinary subpackage

not surprised given RH was gung ho about it until recently

still ouch

Red Hat is enabling it because they need to be able to support migrating SUSE Linux VMs onto OpenShift from VMware

it's disabled on aarch64 because I don't think they've figured out a migration use-case that would justify it commercially

I don't know if the libguestfs stack supports pulling VMs from any other hypervisors to OpenShift or not yet

(libguestfs is the core of the "Migration Toolkit for Virtualization" product feature for OpenShift, it was demoed at Red Hat Summit last year)

oh god so it's even worse for our delta

the big upside though is that I think they will accept contributions to fs/btrfs in the RHEL kernel now

since it is "actively" used

yeah, and I guess it will be in a compileable state

that is beneficial for our downstream work with AlmaLinux

so I guess the kmod SIG has an easier time at this too

yup

so even if the kconfig setup is messed up in the RHEL kernel and ARK, I can deal with it, and it opens the door for the commitments we made to support the Kmods SIG and AlmaLinux on Btrfs to be reasonably executable

I don't know if this is the right chat for this, but I could somewhat contribute to fedora since I have some spare (possibly ARM based) tablets I could use

that's useful, though you should probably join #arm:fedoraproject.org to engage on that front

yeah, this is currently the CentOS Hyperscale meeting :)

so at least wrt btrfs for Enterprise Linux and our efforts to support that: this is going to on a net-basis make things easier for us

it also means that CBS x86 builders can benefit from this for Hyperscale support

we might want to see if they're willing to enable for the other arches in kernel-modules-internal so CBS can use them

since the package is filtered out, it won't have a product impact, and if we can help support it in the RHEL kernel tree, I think that could be a win everywhere

wanna file a jira for that?

sure

hmm, actually

it might be better if you ask

sure, which component?

kernel / storage / something something

we can make an argument for it too

but you should have some kind of completion for it

yeah I think the argument will be stronger when it's not from me

say that if they backport something wrong and it starts failing on some architectures that's probably good signal evenif they don't use it

supporting community use-cases in CentOS I think is a lot stronger from community CentOS leaders :)

there's a kernel / filesystem / btrfs but it's not a valid component for c10s

I hate jira

don't we all

oh well will figure this out later

note you will have to ask for the ticket to be made public right after filing it, as kernel tickets are auto-private by default

oh ... yikes

has this been raised to... FRCL?

though the "this is not a place where actions are taken" is a bit discouraging

it should be raised there, but it hasn't yet, no

that's a conversation for the next meeting :)

anything else for announcements before we move on?

i have a half-question half-announcement

I recently looked at the topic of removing stale projects and kicking out inactive members. I asked Claude Code to vibecode me a report using Gitlab API, and got https://gistpreview.github.io/?133b86c99be8a18c61981d52dd396f3c , which looks more or less correct.

If this type of automated reporting is useful, then I can turn it into a script that we could run from time to time. But most importantly, what thresholds do we want to use? For now I just asked AI to sum up past 1month, 3months, 6months, and 2years of activity. Any ideas what to do instead?

ah, interesting

we might also want to take into account pagure activity, though on the other hand we started moving packages to gitlab a long time ago, right?

so that definitely will be useful going forward, though we might want to vet the result at least the first time

In my opinion using this every like 3 months is a good threshold

we probably want to start initially with a one year horizon

yeah i don't have high confidence in the numbers, i want to at least know where Neal's 5 million commits came from XD

and to from there

and go from there

GitLab attributes mirror pushes to the person who set it up

5 million... yeah oops that sounds bad

the data will be absolutely totally wrong

well that's just dumb :(

there's no way to tell it "look at the author name in the log" ?

yep

I complained when I was the guy paying for GitLab years ago

so I can just clone one repo and be set for life :P

I have a big sea of blue on GitLab :P

I'm super-active yo

I suppose Claude will not be as good as looking at CBS / Koji

because I think that is more meaningful - we're talking about full contributors after all, those with build access

yes

we could also exclude Hyperscale/rpms

pzmarzlywant to see if Claude can do that?

oh right, gitlab will be useful for anything not RPMs like docs

the gitlab API I mean

i can, but shouldn't all our CBS builds originate from gitlab repos?

yup

oh if there is an indication if the repo is mirrored or not that could be useful

yes, but the metrics in Hyperscale/rpms will be a complete mess

yes but with CBS you don't have to filter out too many irrelevant activities

there should be a property to indicate it has pull mirroring set up

but an easy carveout is to use CBS as the proxy for Hyperscale/rpms up front

yeah. and those activities are more meaningful too

I think Fedora also track it that way right? you have to actually have submitted builds

ok, will take a look at reading from CBS

quick googling tells me it has a XML API

yes, XML-RPC

the Koji folks are also in #koji:fedora.im if you want to talk to them

we're running out of time

Koji instances also have their documentation deployed in the instance too: https://cbs.centos.org/koji/api

anyway

yeah

and at least I have a meeting right after this so...

let's close this one out

thanks everyone for the great discussion, and see you soon