#meeting:fedoraproject.org log

<@davide:cavalca.name>

16:01:11

!startmeeting CentOS Hyperscale SIG

<@meetbot:fedora.im>

16:01:13

Meeting started at 2024-06-05 16:01:11 UTC

<@meetbot:fedora.im>

16:01:13

The Meeting name is 'CentOS Hyperscale SIG'

<@davide:cavalca.name>

16:01:22

!topic Roll call

<@davide:cavalca.name>

16:01:27

morning everyone

<@daandemeyer/:matrix.org>

16:01:42

!hi

<@zodbot:fedora.im>

16:01:44

Daan De Meyer (daandemeyer)

<@conan_kudo:matrix.org>

16:01:45

!hi

<@rrbc:matrix.org>

16:01:45

Morning!

<@zodbot:fedora.im>

16:01:47

Neal Gompa (ngompa) - he / him / his

<@jonathanspw:fedora.im>

16:02:25

!hi

<@zodbot:fedora.im>

16:02:26

Jonathan Wright (jonathanspw)

<@jonathanspw:fedora.im>

16:02:30

!bye

<@conan_kudo:matrix.org>

16:02:36

...

<@nhanlon:beeper.com>

16:02:59

!hi

<@zodbot:fedora.im>

16:03:01

Neil Hanlon (neil) - he / him / his

<@davide:cavalca.name>

16:05:48

good showing today, let's get started

<@davide:cavalca.name>

16:05:53

!topic Followups

<@davide:cavalca.name>

16:07:19

anybody has followups to share?

<@davide:cavalca.name>

16:11:37

looks like not, let's move to

<@davide:cavalca.name>

16:11:39

!topic Announcements

<@davide:cavalca.name>

16:11:57

I've updated the conference talks list and the meeting minutes in the docs

<@davide:cavalca.name>

16:12:05

https://sigs.centos.org/hyperscale/communication/talks/

<@davide:cavalca.name>

16:12:12

https://sigs.centos.org/hyperscale/communication/meetings/

<@davide:cavalca.name>

16:12:21

next week a bunch of us will be at devconf.cz

<@davide:cavalca.name>

16:13:02

finally, we are due for quarterly reporting, so we should try and get that sorted out this week

<@davide:cavalca.name>

16:13:16

I can get a hackmd started after this

<@davide:cavalca.name>

16:14:10

anybody else has announcements?

<@conan_kudo:matrix.org>

16:16:11

nothing so far

<@davide:cavalca.name>

16:18:38

alright, off to

<@davide:cavalca.name>

16:18:39

!topic Tickets

<@davide:cavalca.name>

16:21:32

here we go

<@davide:cavalca.name>

16:21:41

I don't think we have any significant update here

<@davide:cavalca.name>

16:21:48

I'll file a ticket later for the quarterly

<@davide:cavalca.name>

16:25:18

!topic Membership

<@conan_kudo:matrix.org>

16:26:25

still waiting on that person to show up in here

<@davide:cavalca.name>

16:26:33

yup, nothing else I think

<@daandemeyer/:matrix.org>

16:28:44

open floor? I have some topics

<@davide:cavalca.name>

16:32:14

!topic Misc

<@davide:cavalca.name>

16:32:24

Daan De Meyer: you have the floor

<@daandemeyer/:matrix.org>

16:32:56

So I already brought this up elsewhere once, but wanted to confirm

<@daandemeyer/:matrix.org>

16:33:06

For systemd 256 my idea is we stop using the pagure repo

<@daandemeyer/:matrix.org>

16:33:13

And instead work directly off systemd-stable

<@daandemeyer/:matrix.org>

16:33:32

Anything FB specific we handle as patches in rpm again

<@daandemeyer/:matrix.org>

16:33:44

And we nuke the pagure repo if it works

<@daandemeyer/:matrix.org>

16:35:15

I'm not 100% sure we want this yet though

<@daandemeyer/:matrix.org>

16:35:57

Since we lose some control, specifically if upstream decides to backport a bunch of commits inbetween, we can't backport just one extra commit anymore

<@daandemeyer/:matrix.org>

16:36:22

We'll always pick up all backports for that release

<@daandemeyer/:matrix.org>

16:36:26

Which might be OK tbh

<@davide:cavalca.name>

16:36:29

this seems like it's potentially more work to maintain

<@davide:cavalca.name>

16:36:38

but you're the one doing the work, so if you're ok with it I'm fine with it

<@davide:cavalca.name>

16:36:48

my only request is to make sure the docs are up to date

<@davide:cavalca.name>

16:37:01

so if folks want to contribute to this and/or understand how it's put together they can

<@daandemeyer/:matrix.org>

16:37:36

My idea is that by doing it this way we do more useful work for everyone

<@daandemeyer/:matrix.org>

16:37:59

Everyone using systemd-stable benefits immediately instead of someone else having to do the same work of backporting to systemd-stable

<@daandemeyer/:matrix.org>

16:39:25

My other topic was about c10s

<@daandemeyer/:matrix.org>

16:39:42

Which seems like it will have 256: https://github.com/redhat-plumbers/systemd-rhel10

<@daandemeyer/:matrix.org>

16:40:05

So we will end up behind immediately

<@conan_kudo:matrix.org>

16:40:45

if they're handling it like the kernel, they'll do rebases until the cutoff point for stabilization, which is a few months away (judging by last time around)

<@conan_kudo:matrix.org>

16:40:56

so we're going to keep falling behind unless we decide to be more aggressive somehow

<@daandemeyer/:matrix.org>

16:42:05

Do we care at all?

<@daandemeyer/:matrix.org>

16:42:24

Or would it just be my pride that is hurt?

<@davide:cavalca.name>

16:42:37

we do, because we don't do vendor pinning for Hyperscale

<@davide:cavalca.name>

16:42:49

so if upstream is ahead they win the version race and it can and will cause issues

<@davide:cavalca.name>

16:43:16

(also internally the automation will bug you about this too)

<@daandemeyer/:matrix.org>

16:43:35

We can't really do anything about it though

<@daandemeyer/:matrix.org>

16:43:41

Except messing with the rpm version field ourselves

<@daandemeyer/:matrix.org>

16:43:44

I guess

<@conan_kudo:matrix.org>

16:44:25

we do care because things link and use libsystemd

<@daandemeyer/:matrix.org>

16:44:26

But that just seems like a recipe for problems later on

<@conan_kudo:matrix.org>

16:44:42

if we're behind RHEL, then we can and do experience weirdness

<@daandemeyer/:matrix.org>

16:46:13

I am open to suggestions

<@daandemeyer/:matrix.org>

16:46:26

But just throwing versions out just to be ahead of RHEL doesn't seem like a good solution

<@conan_kudo:matrix.org>

16:46:37

why not?

<@conan_kudo:matrix.org>

16:47:05

if we're tracking upstream systemd with automation, I'd like to know if there's a good reason not to rebase to a newer version

<@daandemeyer/:matrix.org>

16:48:38

Aside from upstream testing and me booting it in a mkosi VM and updating the selinux policy, I don't do a whole lot of generic testing that's not within FB

<@daandemeyer/:matrix.org>

16:48:52

So I guess we could just throw versions out there as they are released

<@conan_kudo:matrix.org>

16:49:27

is upstream CI testing Hyperscale yet?

<@daandemeyer/:matrix.org>

16:49:48

Every integration test now runs in a mkosi hyperscale image on every PR yes

<@daandemeyer/:matrix.org>

16:50:34

With the caveat that this is with mkosi initrds and systemd-gpt-auto-generator

<@daandemeyer/:matrix.org>

16:50:41

So quite different from a regular centos boot

<@daandemeyer/:matrix.org>

16:51:19

So there's a non zero chance that whatever version I throw out in the wild needs a fix in dracut that isn't there yet

<@conan_kudo:matrix.org>

16:51:39

how difficult would it be to add something that's closer to a real hyperscale environment?

<@daandemeyer/:matrix.org>

16:52:19

Hard, we make a number of initrd customizations and I don't want to maintain those for two initrd generators

<@daandemeyer/:matrix.org>

16:52:41

But Frantisek Sumsal has expressed interest in keeping dracut CI in some form so he might work on this in the future

<@davide:cavalca.name>

16:57:51

we're almost out of time, any last words?

<@pboy:fedora.im>

17:00:00

Folks, just a reminder, in 1 min Server WG meeting is scheduled here.

<@davide:cavalca.name>

17:00:10

yup I was just about to close :)

<@pboy:fedora.im>

17:00:16

hanks

<@pboy:fedora.im>

17:00:19

thanks

<@davide:cavalca.name>

17:00:22

!endmeeting