#meeting-1:fedoraproject.org log

<@ydesouza:fedora.im>

16:30:16

!startmeeting fedora_coreos_meeting

<@meetbot:fedora.im>

16:30:18

Meeting started at 2024-10-30 16:30:16 UTC

<@meetbot:fedora.im>

16:30:18

The Meeting name is 'fedora_coreos_meeting'

<@ydesouza:fedora.im>

16:31:27

!topic roll call

<@ydesouza:fedora.im>

16:32:07

For some reason, the issue for this meeting was not created in to fcos-meeting-action repo.

<@hricky:fedora.im>

16:32:10

!hi

<@zodbot:fedora.im>

16:32:11

Hristo Marinov (hricky) - he / him / his

<@dustymabe:matrix.org>

16:32:36

!hi

<@zodbot:fedora.im>

16:32:38

Dusty Mabe (dustymabe) - he / him / his

<@apiaseck:matrix.org>

16:32:45

!hi

<@zodbot:fedora.im>

16:32:47

Adam Piasecki (c4rt0) - he / him / his

<@ydesouza:fedora.im>

16:33:38

!topic Action items from last meeting

<@ydesouza:fedora.im>

16:34:09

I am manually searching for our last meeting topics

<@ydesouza:fedora.im>

16:35:26

I guess we don't have any action items for the last meeting

<@mnguyen:fedora.im>

16:35:28

!hi mnguyen

<@zodbot:fedora.im>

16:35:29

Michael Nguyen (mnguyen)

<@jbtrystram:matrix.org>

16:35:36

!hi

<@zodbot:fedora.im>

16:35:38

Jean-Baptiste Trystram (jbtrystram) - he / him / his

<@marmijo:fedora.im>

16:36:36

!hi

<@zodbot:fedora.im>

16:36:37

Michael Armijo (marmijo)

<@ydesouza:fedora.im>

16:36:58

So lets discuss our tracker!

<@ydesouza:fedora.im>

16:37:16

https://github.com/coreos/fedora-coreos-tracker/issues/1818

<@ydesouza:fedora.im>

16:37:16

!topic Migrate existing systems to iptables-nft and remove iptables-legacy

<@ydesouza:fedora.im>

16:38:45

Any insights about this one?

<@dustymabe:matrix.org>

16:40:13

travier opened the issue but he isn't around today.

<@dustymabe:matrix.org>

16:40:38

I added the meeting label because I thought it was worth discussing. anyone with expertise on this able to carry on the conversation? if not we can push it to next week

<@jbtrystram:matrix.org>

16:41:23

i have no expertise in that area

<@dustymabe:matrix.org>

16:41:33

same here, not much

<@mnguyen:fedora.im>

16:41:40

ditto

<@ydesouza:fedora.im>

16:42:33

So, lets move on!

<@ydesouza:fedora.im>

16:42:54

We can discuss this next week!

<@ydesouza:fedora.im>

16:42:56

!topic Enable automatic bootloader updates #1468

<@ydesouza:fedora.im>

16:42:56

https://github.com/coreos/fedora-coreos-tracker/issues/1468

<@jlebon:fedora.im>

16:43:20

!hi

<@zodbot:fedora.im>

16:43:21

None (jlebon)

<@dustymabe:matrix.org>

16:45:14

we skipped the alternatives issue Jonathan Lebon because @travier isn't here

<@dustymabe:matrix.org>

16:45:30

this one has heavy @travier involvement too

<@dustymabe:matrix.org>

16:45:31

<@jlebon:fedora.im>

16:46:21

dustymabe: SGTM 👍️

<@jbtrystram:matrix.org>

16:46:31

for this one : it got enabled for atomic desktops for f41

<@jbtrystram:matrix.org>

16:47:00

so it's worth monitoring the fallout there and aim for f42

<@ydesouza:fedora.im>

16:48:03

!info Automatic bootloader updates enabled for atomic desktops for f41

<@jlebon:fedora.im>

16:48:49

excited to see this happen. aiming for f42 makes sense to me

<@dustymabe:matrix.org>

16:49:45

so presumably all SELInux related issues will be fixed soon

<@jbtrystram:matrix.org>

16:49:59

I don't think we'd want to enable that mid cycle, right ?

<@dustymabe:matrix.org>

16:50:16

jbtrystram: not typically, but we could on `next` if we wanted to

<@dustymabe:matrix.org>

16:50:44

I wonder how much extra work it would take for this to work on RAID setups OR if we should just choose to ignore those forever

<@jlebon:fedora.im>

16:51:37

i don't think we should block on RAID support, but it's definitely a gap worth closing. this is relevant for RHCOS too

<@dustymabe:matrix.org>

16:52:38

reading through the issues.. with anaconda only one EFI/ESP partition ever gets created?

<@dustymabe:matrix.org>

16:52:51

what happens if a full disk fails?

<@jlebon:fedora.im>

16:54:08

dustymabe: interesting. if that's the case, i'd expect boot failure (if it's the disk with the ESP)

<@dustymabe:matrix.org>

16:55:15

part of me thinks we should just auto update the booted disk ESP even on RAID - after all the config is just a stub isn't it (that points to the /boot partition, which is RAIDED)?

<@dustymabe:matrix.org>

16:56:23

part of me thinks we should just auto update the booted disk ESP even on RAID - after all the config is just a stub isn't it (that points to the /boot partition, which is mirrored)?

<@jlebon:fedora.im>

16:57:03

the firmware blobs are on the ESP

<@jlebon:fedora.im>

16:58:46

FWIW i don't think this should be very hard for bootupd to implement

<@dustymabe:matrix.org>

16:59:36

ok then let's move forward with F42 and maybe we can get someone with free cycles to implement it?

<@dustymabe:matrix.org>

17:02:51

at one point when we discussed this in the past we did mention that we should update bootloader, but that maybe every update wasn't the right frequency. one option was every major update, versus every update

<@dustymabe:matrix.org>

17:02:51

<@dustymabe:matrix.org>

17:02:51

i'm not sure if it's worth the extra logic, but just mentioning in case we think that's what we should do

<@ydesouza:fedora.im>

17:05:11

So everyone agrees with move forward with F42? So I can post a agreement in the meeting. :)

<@jlebon:fedora.im>

17:06:47

dustymabe: i vaguely recall that, yeah. OTOH, it won't actually be every update, but every update containing a new e.g. grub2 (or shim, which is extremely rare)

<@ydesouza:fedora.im>

17:07:09

!agreed Move forward with F42 and get someone with free cycles to implement 👍

<@jbtrystram:matrix.org>

17:07:24

dustymabe: now that we have stronger guarantees around the safety of the process, updating it every update sounds reasonnable to me, at least for UEFI

<@dustymabe:matrix.org>

17:10:30

Jonathan Lebon: jbtrystram should we bring any updates here on our strategy going forward for switching over to containers for updates?

<@jbtrystram:matrix.org>

17:10:59

sure !

<@dustymabe:matrix.org>

17:11:37

maybe let's start a new topic and then do the update in that

<@ydesouza:fedora.im>

17:12:57

This was the last topic for today. Now I will start the open floor.

<@ydesouza:fedora.im>

17:13:07

!topic Open Floor

<@dustymabe:matrix.org>

17:14:55

jbtrystram: or Jonathan Lebon want to do the update? otherwise I can try

<@jlebon:fedora.im>

17:15:19

sure, i can do it

<@jbtrystram:matrix.org>

17:15:28

let me try :)

<@jbtrystram:matrix.org>

17:22:01

At this point, zincati will call `rpm-ostree rebase` instead of `rpm-ostree update`

<@jbtrystram:matrix.org>

17:22:01

Note that nodes will not follow a moving tag like `stable` but be rebased to specific builds, allowing to keep the barrier release feature

<@jbtrystram:matrix.org>

17:22:01

release.json will also start carrying the OCI pullspec for a given build.

<@jbtrystram:matrix.org>

17:22:01

We have come up with a plan to migrate FCOS to container images for update to replace the OSTree server.

<@jbtrystram:matrix.org>

17:22:01

First, we will do a barrier update with an update to Zincati to understand a new scheme value of `oci` in the update graph.

<@jbtrystram:matrix.org>

17:22:01

Then, cincinnati will learn to serve a separate update graph referencing containers pullspecs when the client manifest itself as "oci-ready"

<@jbtrystram:matrix.org>

17:24:07

In a second step, we will teach zincati to read the update guidance from a static JSON file (either from a static well-known URL or an OCI artifact in the repository), so the cincinati server can be decomissionned in the long term

<@jlebon:fedora.im>

17:24:30

yeah, a very specific UX change here worth surfacing is that with this approach `rpm-ostree upgrade` will no longer work

<@jbtrystram:matrix.org>

17:25:29

dustymabe: Jonathan Lebon I tried to summarize the design document we wrote last time. Should we share the link here for more details ? Do you have anything to add ?

<@jlebon:fedora.im>

17:25:40

we could do things in a way that keeps it working. though OTOH maybe we don't want to do that

<@dustymabe:matrix.org>

17:26:58

jbtrystram: Jonathan Lebon would F42 we think be a reasonable timeframe for the first phase of this?

<@jlebon:fedora.im>

17:27:46

dustymabe: i want to say yes, but it still needs to be prioritized against the other things going on in that same timeframe

<@jbtrystram:matrix.org>

17:29:22

F42 would be great to aim for !

<@jlebon:fedora.im>

17:29:25

fwiw, i started on the metadata part of this at least to get the pullspec information into the release and release index metadata

<@dustymabe:matrix.org>

17:30:37

i.e. work on the Cincinnati side?

<@dustymabe:matrix.org>

17:31:07

oh no. you means on the streams side

<@jlebon:fedora.im>

17:31:10

not quite. the files that Cincinnati reads :)

<@hricky:fedora.im>

17:32:10

Could you share the link to the design document you mentioned?

<@ydesouza:fedora.im>

17:32:49

Hey team, we are already out of time. What do you think about continue to discuss this async in our channel?

<@dustymabe:matrix.org>

17:33:16

oh no. you mean on the streams side

<@jlebon:fedora.im>

17:34:32

Hristo Marinov: that doc is full of crud from lots of different discussions. i think we need to extract from it the relevant parts for this and put it in the tracker ticket

<@jbtrystram:matrix.org>

17:35:02

Hristo Marinov: https://hackmd.io/VamuZWxFSBGv68PCB_5tCw

<@jbtrystram:matrix.org>

17:35:14

oops

<@dustymabe:matrix.org>

17:35:14

Yasmin Valim de Souza: yep. I think we're done

<@ydesouza:fedora.im>

17:35:41

Nice! See you all next week! Thanks for the discussion!

<@jbtrystram:matrix.org>

17:35:47

yeah i was going to say, should we set an action item to synthetize that into a tracking issue ?

<@ydesouza:fedora.im>

17:35:59

Sure!

<@jbtrystram:matrix.org>

17:36:21

Sorry Yasmin i know we are out of time but the intend was to share our async work with the community

<@jlebon:fedora.im>

17:36:22

hmm, i thought we had one, but the closest is https://github.com/coreos/fedora-coreos-tracker/issues/1263 which intermingles the layering part

<@jlebon:fedora.im>

17:36:31

i will create a tracker issue

<@jbtrystram:matrix.org>

17:36:38

so moving back to async defeats that :)

<@ydesouza:fedora.im>

17:36:58

No problem, jbtrystram

<@jbtrystram:matrix.org>

17:37:15

we have https://github.com/coreos/fedora-coreos-tracker/issues/1726 as well

<@jlebon:fedora.im>

17:37:46

yeah, will link it from there

<@jlebon:fedora.im>

17:39:15

(good to end this meeting from my side)

<@ydesouza:fedora.im>

17:39:27

Nice! See you all!

<@ydesouza:fedora.im>

17:39:34

!endmeeting