#meeting:fedoraproject.org log

<@davide:cavalca.name>

15:03:48

!startmeeting CentOS Hyperscale SIG

<@meetbot:fedora.im>

15:03:49

Meeting started at 2025-09-10 15:03:48 UTC

<@meetbot:fedora.im>

15:03:49

The Meeting name is 'CentOS Hyperscale SIG'

<@michel-slm:matrix.org>

15:03:56

!hi

<@zodbot:fedora.im>

15:03:58

Michel Lind (salimma) - he / him / his

<@davide:cavalca.name>

15:03:59

morning folks

<@davide:cavalca.name>

15:04:01

!topic Roll call

<@conan_kudo:matrix.org>

15:04:11

!hi

<@zodbot:fedora.im>

15:04:13

Neal Gompa (ngompa) - he / him / his

<@rcolebaugh:matrix.org>

15:06:01

!hi

<@zodbot:fedora.im>

15:06:03

Raymond Colebaugh (rcolebaugh) - he / him / his

<@noxiouz:fedora.im>

15:06:32

!hi

<@zodbot:fedora.im>

15:06:33

Anton Tiurin (noxiouz)

<@davide:cavalca.name>

15:06:51

let's get started

<@davide:cavalca.name>

15:06:56

!topic Followups

<@davide:cavalca.name>

15:07:03

any followups from the last meeting?

<@conan_kudo:matrix.org>

15:07:49

I've released kernel 6.16 for hyperscale 10 and hyperscale asahi 10

<@conan_kudo:matrix.org>

15:08:19

but not hyperscale 9 because somehow the build is broken on cs9

<@conan_kudo:matrix.org>

15:09:48

the internal bpftool didn't build and it didn't fail on that, it failed when a following step couldn't load the built bpftool

<@michel-slm:matrix.org>

15:09:57

speaking of kernel and c9s I am going to try building the Fedora kernel, but the userspace parts only (so basically kernel-tools)

<@michel-slm:matrix.org>

15:10:10

since we are blocked on updating perf because the tarball is missing files on aarch from 6.15 onwards

<@conan_kudo:matrix.org>

15:10:18

ugh how?

<@conan_kudo:matrix.org>

15:10:24

isn't the tarball creation automated?

<@michel-slm:matrix.org>

15:10:27

some files are now pregenerated

<@conan_kudo:matrix.org>

15:10:32

<@michel-slm:matrix.org>

15:10:56

yeah, it's reported upstream but acme hasn't fixed it yet. I should try if it's fixed for 6.16, but seems like ... dangerous when no distro used that tarball

<@michel-slm:matrix.org>

15:11:05

maybe we should buy acme a nice ARM laptop and that would solve it

<@michel-slm:matrix.org>

15:11:12

(since we don't care about ppc and s390)

<@conan_kudo:matrix.org>

15:11:29

it might be worth it :/

<@davide:cavalca.name>

15:13:59

!topic Announcements

<@davide:cavalca.name>

15:14:12

I've untagged some old builds the other week

<@davide:cavalca.name>

15:14:54

at some point it'd be nice to resurrect the automation for this instead of doing it by hand, but it's usually only a handful every month or so

<@davide:cavalca.name>

15:14:56

so it's not too bad

<@davide:cavalca.name>

15:16:05

tangentially related to Hyperscale, Michel and I will be at ASG later in the month talking about Proposed Updates

<@davide:cavalca.name>

15:16:45

and also on that front, I'm looking as rebasing liburing in c9s, abidiff is clean so I'll file a jira for it after this meeting

<@davide:cavalca.name>

15:17:01

anybody else has announcements to share?

<@michel-slm:matrix.org>

15:17:53

I will try and get the website up next week and we should figure out how to spin this as I think the ASG track is 'security'

<@davide:cavalca.name>

15:18:15

yeah let's sit down next week and write this

<@davide:cavalca.name>

15:19:17

!topic Tickets

<@davide:cavalca.name>

15:19:30

did we schedule the cleanup that we discussed the last time?

<@michel-slm:matrix.org>

15:19:42

ticket cleanup, or membership roster cleanup? or both

<@conan_kudo:matrix.org>

15:19:42

nope

<@davide:cavalca.name>

15:19:51

ticket in this context, but we do need to do both

<@davide:cavalca.name>

15:19:58

Conan Kudo: when are you back from Europe?

<@michel-slm:matrix.org>

15:19:58

oh I remember, we could not find a time that works before Neal and I have to travel

<@conan_kudo:matrix.org>

15:20:01

I'm heading back home from Berlin on Saturday

<@davide:cavalca.name>

15:20:17

do we want to try and do this next week?

<@conan_kudo:matrix.org>

15:20:24

should be okay

<@conan_kudo:matrix.org>

15:20:40

next week I'll be traveling by train to Boston, so it should be reasonable

<@davide:cavalca.name>

15:20:41

say, 8-9am PT on Wed? (basically this same slot)

<@michel-slm:matrix.org>

15:20:46

yeah

<@michel-slm:matrix.org>

15:21:03

I set myself to working from the office Tue-Thu so that works

<@conan_kudo:matrix.org>

15:21:05

oh yeah that's fine

<@davide:cavalca.name>

15:21:10

ok I'll book it

<@davide:cavalca.name>

15:21:22

and if we run over we can use the social on the same day later in the afternoon

<@conan_kudo:matrix.org>

15:21:34

yup

<@davide:cavalca.name>

15:21:51

!topic Membership

<@davide:cavalca.name>

15:22:01

we have a few membership requests to process

<@davide:cavalca.name>

15:22:33

https://pagure.io/centos-sig-hyperscale/sig/issue/199 for Yaping Li , https://pagure.io/centos-sig-hyperscale/sig/issue/198 for Anton Tiurin and https://pagure.io/centos-sig-hyperscale/sig/issue/197 for James (who I can't find on Matrix)

<@yaping.li:matrix.org>

15:22:58

Hello, this is Yaping

<@noxiouz:fedora.im>

15:23:28

hi, folks! I am Anton. I started working on systemd recently. Very happy to be there and help as much as I can

<@michel-slm:matrix.org>

15:23:41

we should ping James' ticket and tell him our meeting times, I feel like this happened in a previous meeting already

<@davide:cavalca.name>

15:23:56

yeah I pinged it already, will do it again

<@davide:cavalca.name>

15:24:10

for context Yaping and Anton work at Meta on the same team as Michel and I

<@rcolebaugh:matrix.org>

15:24:50

Nice, welcome Yaping and Anton!

<@davide:cavalca.name>

15:25:11

if there aren't any objections I'll process these two after the meeting

<@rcolebaugh:matrix.org>

15:26:08

No objections from me 😃

<@michel-slm:matrix.org>

15:27:59

I feel like being in the same team I should not be the first person to respond :)

<@davide:cavalca.name>

15:28:20

eh, we've never been particularly strict with quorum on these either

<@davide:cavalca.name>

15:28:33

I usually just run the clock for 5 min

<@davide:cavalca.name>

15:30:42

!agreed welcome Anton Tiurin Yaping Li to the CentOS Hyperscale SIG

<@davide:cavalca.name>

15:30:58

I'll get the paperwork done after the meeting

<@davide:cavalca.name>

15:31:00

this leaves us with

<@davide:cavalca.name>

15:31:08

!topic Miscellaneous

<@davide:cavalca.name>

15:31:12

anything else folks want to discuss?

<@conan_kudo:matrix.org>

15:31:59

I'd like for us to discuss a formal policy of Stream Hyperscale lifecycle

<@michel-slm:matrix.org>

15:32:05

oh yes

<@conan_kudo:matrix.org>

15:32:58

Particularly, I'd like to propose we only have _one year_ overlap maximum for multiple CentOS Stream releases being supported

<@conan_kudo:matrix.org>

15:33:55

e.g. Hyperscale 9 should be supported for only one more year after Hyperscale 10 has been made available

<@conan_kudo:matrix.org>

15:34:24

the ability to support producing kernel updates and images rapidly degrades after a new CentOS Stream release is done upstream

<@davide:cavalca.name>

15:35:01

would it make sense to restrict this to kernel and images?

<@davide:cavalca.name>

15:35:30

my concern is that from past experience, a one year window is very tight for a migration, and even when things go perfectly well there's always a long tail

<@davide:cavalca.name>

15:36:09

with my Meta hat on, we will definitely need to be able to keep building and shipping packages for the old release after one year to deal with that

<@davide:cavalca.name>

15:36:35

but regardless I do like the idea of having a public policy around this, as it'll help act as a forcing function for folks to move as well

<@salimma:fedora.im>

15:37:06

yeah I think having it tiered makes sense

<@davide:cavalca.name>

15:37:17

we're somewhat late in the c9s cycle already, so I think we should _probably_ announce this for the 10/11 cycle and leave c9s alone to avoid surprising people

<@conan_kudo:matrix.org>

15:38:08

keep in mind that there's only 2 years left for a CentOS Stream release after a new one is out

<@salimma:fedora.im>

15:38:13

maybe after the fourth year call it maintenance only (or whatever RHEL and Ubuntu LTS call it) and basically say we will only do needed userspace tooling and not do kernel and images?

<@conan_kudo:matrix.org>

15:38:40

so we already will need to wind it down at the end of next year

<@salimma:fedora.im>

15:38:44

we certainly will still need to build packages in the last year

<@salimma:fedora.im>

15:39:03

unfortunate but true

<@conan_kudo:matrix.org>

15:39:12

yeah

<@conan_kudo:matrix.org>

15:39:17

we can certainly do a sliding scale

<@conan_kudo:matrix.org>

15:39:30

systemd, kernel, and images are where the biggest pains are

<@davide:cavalca.name>

15:40:09

I'm not worried about systemd tbh, we have a number of folks at Meta taking care of that and the releng pipeline is actively getting worked on

<@conan_kudo:matrix.org>

15:40:48

yes, but there are related things like selinux, undeclared userspace library incompatibility (due to dlopen strategy), and others

<@davide:cavalca.name>

15:41:14

the selinux stuff is significantly less painful after we switched to the backported policy

<@conan_kudo:matrix.org>

15:41:17

the effort to address those gets more difficult over time

<@davide:cavalca.name>

15:41:22

but yeah, I agree this isn't free for sure

<@conan_kudo:matrix.org>

15:41:37

I think we should consider the sliding scale and have a public policy

<@conan_kudo:matrix.org>

15:41:43

doesn't mean we can't have exceptions as needed

<@conan_kudo:matrix.org>

15:41:49

but having a policy creates a strong forcing function

<@davide:cavalca.name>

15:41:59

yeah I'm fine with that

<@conan_kudo:matrix.org>

15:42:01

it also helps with planning, I would hope

<@salimma:fedora.im>

15:42:08

also with bug reports I guess

<@conan_kudo:matrix.org>

15:42:14

yup

<@davide:cavalca.name>

15:42:20

do you want to draft something in a hackmd/PR/whatever and we can bikeshed it in the next meeting?

<@salimma:fedora.im>

15:42:24

we can say hey after this date, this is only people building it for narrower use cases

<@conan_kudo:matrix.org>

15:42:27

yeah, sure

<@conan_kudo:matrix.org>

15:42:35

absolutely

<@salimma:fedora.im>

15:42:38

worst case we can even just start building these as hs+fb instead of hs

<@davide:cavalca.name>

15:42:42

meanwhile Michel and I will start socializing that this is coming internally

<@conan_kudo:matrix.org>

15:42:52

excellent

<@conan_kudo:matrix.org>

15:43:45

the main driver for this is that it takes half a day of effort to troubleshoot even a single mess of failures with kernel builds, so I'd like to have guardrails for how much I have to care over time

<@conan_kudo:matrix.org>

15:44:06

especially when failures can be CBS-only, which is frustrating

<@conan_kudo:matrix.org>

15:44:37

(this is not the first time I've had such problems either)

<@conan_kudo:matrix.org>

15:45:09

it also should help us deal with scoping for security response too

<@conan_kudo:matrix.org>

15:45:14

which we really need to have a policy for

<@salimma:fedora.im>

15:45:17

yeah, and Meta does not consume the public kernel anyway

<@salimma:fedora.im>

15:45:29

so being able to focus mostly on one release is useful

<@conan_kudo:matrix.org>

15:46:10

and we probably want even _tighter_ constraints for Hyperscale Asahi

<@salimma:fedora.im>

15:47:23

yeah

<@salimma:fedora.im>

15:47:30

that can be a sub-policy though I guess?

<@salimma:fedora.im>

15:47:59

just cut them off as soon as we have the new release ready and a decision on upgrade path (either say upgrades are supported or upgrades are not supported and please reimage)

<@conan_kudo:matrix.org>

15:48:49

yup

<@salimma:fedora.im>

15:51:39

anything else people want to bring up?>

<@davide:cavalca.name>

15:52:25

nothing from me

<@davide:cavalca.name>

15:54:10

I think that's it for today

<@davide:cavalca.name>

15:54:13

thanks everyone and see you soon

<@davide:cavalca.name>

15:54:16

!endmeeting