#meeting-1:fedoraproject.org log

<@ydesouza:matrix.org>

16:30:09

!startmeeting fedora_coreos_meeting

<@meetbot:fedora.im>

16:30:13

Meeting started at 2024-05-08 16:30:09 UTC

<@meetbot:fedora.im>

16:30:13

The Meeting name is 'fedora_coreos_meeting'

<@ydesouza:matrix.org>

16:30:22

!topic roll call

<@dustymabe:matrix.org>

16:31:01

!hi

<@zodbot:fedora.im>

16:31:04

Dusty Mabe (dustymabe) - he / him / his

<@aaradhak:matrix.org>

16:31:19

!hi aaradhak

<@zodbot:fedora.im>

16:31:33

Aashish Radhakrishnan (aaradhak)

<@hricky:fedora.im>

16:32:11

!hi

<@zodbot:fedora.im>

16:32:13

Hristo Marinov (hricky) - he / him / his

<@jlebon:fedora.im>

16:32:20

!hi

<@zodbot:fedora.im>

16:32:23

None (jlebon)

<@marmijo:fedora.im>

16:32:26

!hi

<@zodbot:fedora.im>

16:32:28

Michael Armijo (marmijo)

<@gurssing:matrix.org>

16:32:49

!hi gursewak

<@zodbot:fedora.im>

16:32:51

Gursewak Singh (gursewak)

<@ydesouza:matrix.org>

16:34:34

!topic Action items from last meeting

<@ydesouza:matrix.org>

16:35:19

I don't think we have any action items from the last meeting. There is anyone who wants to talk it or can I proceed?

<@dustymabe:matrix.org>

16:36:56

sounds good to proceed

<@ydesouza:matrix.org>

16:37:37

!topic URL for most recent artifact for platform+stream? !link https://github.com/coreos/fedora-coreos-tracker/issues/625

<@dustymabe:matrix.org>

16:38:31

I tagged this in. We had someone recently come in channel talking about netboot.xyz

<@dustymabe:matrix.org>

16:38:52

which is basically a thin helper that has a bunch of different ipxe configs for different Operating systems

<@dustymabe:matrix.org>

16:38:58

it has FCOS!

<@jlebon:fedora.im>

16:39:32

woah, the demo at https://netboot.xyz/docs/ is pretty cool

<@dustymabe:matrix.org>

16:39:46

the problem is that the definitions for FCOS are always out of date

<@dustymabe:matrix.org>

16:40:11

they have some automation that updates it, but then netboot has to do a new release, etc..

<@dustymabe:matrix.org>

16:40:53

AFAICT there is no way in ipxe that we could configure it to grab our stream metadata and then get the necessary PXE artifacts from that

<@dustymabe:matrix.org>

16:41:13

i.e. we'd definitely need a "latest" link if we wanted to make this easier

<@dustymabe:matrix.org>

16:41:34

flatcar has that - so when you install flatcar with netboot.xyz you always get the newest version

<@dustymabe:matrix.org>

16:42:14

So there are a few questions to answer.

<@dustymabe:matrix.org>

16:42:39

1. do we think having stable links for the latest in our streams would be bad?

<@dustymabe:matrix.org>

16:43:00

if we don't think it would be bad then the real question is.. how much effort is it worth?

<@jlebon:fedora.im>

16:44:27

https://github.com/coreos/fedora-coreos-tracker/issues/625#issuecomment-697943279 brings up an important aspect

<@jlebon:fedora.im>

16:45:17

we'd need stable links for our sigs too at least

<@dustymabe:matrix.org>

16:45:51

Jonathan Lebon: fair.. we could limit the artifacts we have stable links for to ones that we find fitting the requirements

<@jlebon:fedora.im>

16:46:27

hmm, i wonder if iPXE has any support for signatures

<@jlebon:fedora.im>

16:47:21

ok yes, it does have some infrastructure around that

<@jlebon:fedora.im>

16:47:31

https://ipxe.net/cmd/imgverify https://ipxe.net/cmd/imgtrust

<@jlebon:fedora.im>

16:48:17

but unclear where the keyring comes from

<@jlebon:fedora.im>

16:49:11

dustymabe: i.e. only have stable links for the PXE artifacts?

<@jlebon:fedora.im>

16:49:51

i wouldn't mind having stable links for all of them, but yeah we'd want to link the sigs too and when documenting them, always show sig verification

<@dustymabe:matrix.org>

16:50:01

possibly.. I mean I personally would just create stable links for all of them and then let users make their own choices

<@dustymabe:matrix.org>

16:50:44

but if we decide we don't like that part of it enough, then we could limit it to just enabling certain workflows

<@jlebon:fedora.im>

16:51:01

if we had an example that documents using ipxe verification, that'd be pretty sweet

<@jlebon:fedora.im>

16:51:29

but i also think that people pxe booting directly from the canonical artifacts would be rare (vs mirroring them closer first)

<@sam:samcday.com>

16:52:09

IIRC that's "sort of" up to the system administrator. You specify `TRUST=ca.crts` when you build iPXE. In reality everyone just uses the pre-builts which follows the mozilla CA crts: https://ipxe.net/crypto#trusted_root_certificates

<@jlebon:fedora.im>

16:52:22

in which case, stable links would be more about making mirroring easier. but it's not that hard to parse the JSON too

<@dustymabe:matrix.org>

16:52:24

I think I disagree. It probably depends on how heavy of a user you are

<@dustymabe:matrix.org>

16:53:11

for example I imagine this workflow is quite common to get OS on platforms that don't formally support it: https://netboot.xyz/docs/kb/providers/equinixmetal

<@dustymabe:matrix.org>

16:54:09

In that list is OCI, Linode, Equinix, -> all of which we don't have official images for

<@dustymabe:matrix.org>

16:55:28

so.. implementation wise. I see two options: 1. just copy the artifacts and rename them to a different folder in s3 2. implement a small redirector service

<@jlebon:fedora.im>

16:55:45

ok, i think i understand what this is doing... that seems very far from mainstream though

<@dustymabe:matrix.org>

16:56:18

define mainstream :)

<@jlebon:fedora.im>

16:57:38

i do like though the "a way to boot FCOS on new platforms" bit

<@dustymabe:matrix.org>

16:58:07

removing steps for ipxe workflows I think will help users trying out FCOS for the first time (or occasional users who re-install ~9-12mo)

<@jlebon:fedora.im>

16:58:46

right, i can more imagine for people kicking the tires than more production-y instances

<@dustymabe:matrix.org>

16:58:49

though, if you're going to install hundreds of systems in your lab or datacenter - I agree, you don't want to repull the PXE artifacts for each boot

<@jlebon:fedora.im>

16:59:37

anyway, it's purely my opinion. i don't have a way to quantify things either way. i would probably still mirror it even if it's just for my server in the basement.

<@dustymabe:matrix.org>

17:00:07

thoughts on ^^

<@dustymabe:matrix.org>

17:00:28

anyone else have opinions?

<@jlebon:fedora.im>

17:02:07

the main difference i see is in 1, there's room for inconsistency (bad) but it's less work (good). in 2, it's always up to date (good), but it's more work (bad)

<@jmarrero:matrix.org>

17:02:36

I don't know enough to understand why we can't just have a link to be added as part of the CI process that publishes the images right now.

<@dustymabe:matrix.org>

17:03:39

jmarrero: if it's a redirect then it's just a link that redirects to the actual location if it's a just a copy then it's not a redirect, it's an actual link, just to a location/filename that's not unique to the version

<@dustymabe:matrix.org>

17:03:57

> in 1, there's room for inconsistency (bad)

<@dustymabe:matrix.org>

17:04:07

> in 1, there's room for inconsistency (bad) Jonathan Lebon can you elaborate?

<@jlebon:fedora.im>

17:04:23

i think this is talking about TLS certificates though, not GPG key verification

<@jmarrero:matrix.org>

17:05:50

I like the idea of the redirect and just get's auto updated.

<@jlebon:fedora.im>

17:06:15

dustymabe: the stream metadata is canonical. adding secondary sources of truth means introducing risks for things being out of date

<@jlebon:fedora.im>

17:06:59

whereas a redirector doesn't introduce another source of truth

<@dustymabe:matrix.org>

17:07:34

Jonathan Lebon: fair, but worst case you boot the 2 week old FCOS I guess? I would see us just running something as part of the release process (similar to how we update the image family in GCP) to update this

<@dustymabe:matrix.org>

17:09:00

I guess in the interest of time we can talk about implementation later? or is it worth going deeper into that now?

<@jmarrero:matrix.org>

17:09:18

https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-page-redirect.html

<@jlebon:fedora.im>

17:09:23

yeah, that sounds good. maybe keep it async in the ticket?

<@dustymabe:matrix.org>

17:09:54

jmarrero: yeah I think that's only if you are hosting a static site (like a website) in s3

<@dustymabe:matrix.org>

17:10:08

Jonathan Lebon: +1

<@dustymabe:matrix.org>

17:10:18

maybe we can agree on direction here, though?

<@jmarrero:matrix.org>

17:10:22

iPXE would not be able to follow the link from a static html that gets updated with every release?

<@dustymabe:matrix.org>

17:10:50

jmarrero: iPXE won't follow redirects?

<@dustymabe:matrix.org>

17:11:03

if that's true then it limits our options probably to `1.` :)

<@jmarrero:matrix.org>

17:11:07

I am asking*

<@jmarrero:matrix.org>

17:11:33

anyway lets move on :D

<@jlebon:fedora.im>

17:11:34

i'd be very surprised if it didn't

<@ydesouza:matrix.org>

17:11:59

I will set this as an action, so you can discusse more about it async. Thats ok?

<@dustymabe:matrix.org>

17:12:34

should we do a proposed/agreed? or I could just `!info`

<@dustymabe:matrix.org>

17:12:59

Yasmin de Souza: probably not super important, so maybe we don't need an action item

<@ydesouza:matrix.org>

17:14:40

Okay! How about a just a info? :)

<@ydesouza:matrix.org>

17:15:01

Just to keep tracking about this task.

<@dustymabe:matrix.org>

17:15:12

sounds good! I'll type something up

<@dustymabe:matrix.org>

17:15:16

Jonathan Lebon: FYI: https://ipxe.org/crypto#trusted_root_certificates

<@sam:samcday.com>

17:16:08

Hum - I don't think iPXE does gpg verification, only x509 code signing certs

<@dustymabe:matrix.org>

17:16:11

!info to enable use cases like netboot.xyz (and iPXE in general) we think it would be beneficial to have stable links people can use. We're not sure 100% on which implementation would be most appropriate yet, though.

<@ydesouza:matrix.org>

17:16:24

Thanks Dusty!

<@dustymabe:matrix.org>

17:16:28

that info look OK>

<@dustymabe:matrix.org>

17:16:32

that info look OK?

<@ydesouza:matrix.org>

17:16:56

Loks nice! Thank you again! So, lets to o our open floor!

<@ydesouza:matrix.org>

17:17:06

!topic Open Floor

<@jlebon:fedora.im>

17:17:41

yes sorry, i was reading more on that now

<@jlebon:fedora.im>

17:18:09

the example code in https://ipxe.net/cmd/imgverify made it look very GPG like, but the note at the bottom of the page clears it up

<@dustymabe:matrix.org>

17:18:20

!info Fedora 40 based coreos is getting shipped out to `stable` stream nodes over the next few days!

<@dustymabe:matrix.org>

17:18:37

We should probably start tracking change proposals for the F41 release

<@jlebon:fedora.im>

17:18:57

https://ipxe.net/crypto#code_signing

<@ydesouza:matrix.org>

17:19:14

Do we already have a document for it where we can track proposes?

<@dustymabe:matrix.org>

17:19:57

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

<@dustymabe:matrix.org>

17:20:35

I guess I'll need to find a volunteer to take over the driving of that discussion and the process around it for the F41 cycle (since I won't be around for most of it)

<@dustymabe:matrix.org>

17:21:35

!action dustymabe to find someone to help wrangle changes considerations for the F41 cycle

<@jlebon:fedora.im>

17:21:59

thankfully, we've been pretty good at keeping the checklist up to date

<@jmarrero:matrix.org>

17:22:00

Talking about proposals, reviews and additional owners welcomed on: https://fedoraproject.org/wiki/Changes/DNFAndBootcInImageModeFedora

<@jlebon:fedora.im>

17:22:15

oh i see, change proposals, yes.

<@dustymabe:matrix.org>

17:22:34

yeah, the change proposals are less well defined at this point

<@dustymabe:matrix.org>

17:22:42

another thing I've been thinking about too.. we really are lacking by not having a proper firewall management tool in FCOS

<@jlebon:fedora.im>

17:22:50

might be good to document that script and how it's run somewhere in the tracker itself

<@jlebon:fedora.im>

17:22:58

i tried once i think and didn't get it to work

<@dustymabe:matrix.org>

17:23:07

https://mastodon.social/@deflockcom/112378364735796507

<@dustymabe:matrix.org>

17:23:50

basically if you run FCOS in a cloud, then yes cloud firewall/security groups, etc. if you run it on bare metal or in a bespoke environment, you really want a firewall

<@dustymabe:matrix.org>

17:25:19

I think the argument would be easier if firewalld was written in !python - but I don't see that changing

<@jlebon:fedora.im>

17:25:50

https://github.com/coreos/layering-examples/blob/main/ansible-firewalld/Containerfile is relevant here

<@dustymabe:matrix.org>

17:26:20

ehh, is it though

<@dustymabe:matrix.org>

17:26:44

I understand what you are saying, but feels kind of like firewall should be table stakes

<@jlebon:fedora.im>

17:26:47

obviously a different kind of message. i.e. firewalling wouldn't feel built in

<@dustymabe:matrix.org>

17:26:55

right

<@sam:samcday.com>

17:27:45

Related: https://github.com/coreos/fedora-coreos-tracker/issues/1623#issuecomment-1851904401

<@dustymabe:matrix.org>

17:28:00

maybe we should have a more focused discussion on this at some point

<@dustymabe:matrix.org>

17:28:08

Yasmin de Souza: i'm done blabbing :)

<@sam:samcday.com>

17:28:16

UDisks2 needs python. CoreOS ships fwupdmgr by default but it chokes without udisks2

<@ydesouza:matrix.org>

17:28:29

Thanks for the discussion today, folks!

<@jlebon:fedora.im>

17:28:53

i feel like you should also be able to do firewalling from a container. one problem of course is bootstrap

<@jlebon:fedora.im>

17:28:54

i feel like you should also be able to do firewalling from a container. one problem of course is bootstrapping

<@jlebon:fedora.im>

17:29:25

thanks Yasmin de Souza for running!

<@dustymabe:matrix.org>

17:29:45

yep.

<@ydesouza:matrix.org>

17:30:00

Have a nice week, everyone!

<@ydesouza:matrix.org>

17:30:11

!endmeeting