Meeting started at 2024-05-22 16:31:46 UTC

The Meeting name is 'fedora_coreos_meeting'

!hi

Timothée Ravier (siosm) - he / him / his

!hi

Michael Armijo (marmijo)

!hi

Hristo Marinov (hricky) - he / him / his

!hi ravanelli

Renata Ravanelli (ravanelli)

!hi

Dusty Mabe (dustymabe) - he / him / his

!hi jasonbrooks

Jason Brooks (jasonbrooks) - he / him / his

!hi

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

let's wait another minute

ok, let's get started!

ACTION: All to think about the python discussion ACTION: ravanelli to contact the libteam maintainers to figure out if they intend to drop the package from fedora

!hi aaradhak

!hi

i think a few of us have done the former. Renata Ravanelli did you do the second one yet?

Aashish Radhakrishnan (aaradhak)

Jason Blackwell (blackwell)

!hi

Noel Miller (dogphilosopher)

dogphilosopher: 👋

Jonathan Lebon: sorry, not yet. I will

Renata Ravanelli: ack, sounds good! i'll re-action it then

ok, let's move to topics

!link https://github.com/coreos/fedora-coreos-tracker/issues/1732

travier: want to introduce this one?

Shouldn't we do the Python discussion first?

But I can speak about this one

But I can also speak about this one

The idea is that it's non-intuitive for users to use stable names for disks for partionning using Ignition and for a good reason: as soon as you do it, your config is not generic anymore

moreover, you usually don't know that you need it until you ran into issues and it's usually too late then

i'm fine with swapping if you'd like. that's the order it was in in the checklist :)

So instead of forcing everyone to have node specific configs, I think we should have something, maybe in Ignition, "specialize" the mount units to reference stable names

so i think there are two separate issues at play here

we could run that logic on existing nodes as well as that would make the setup more robust to future name changes

the first is that it's hard to reference block devices in a reliable way in the storage.disks and storage.filesystems sections. the second is that your mount unit can be written in a way that breaks between boots/in an upgrade.

the second issue I would argue is actually mostly a documentation problem

to me it's all interconnected

not just of course. e.g. i think with_mount_units could be made smarter

you are not going to write the mount units manually; they are written by ignition

right. so i think one improvement we could make here is to add a lint for this in butane

today I think with_mount_units is butane sugar, right?

first, if you use `with_mount_unit: true`, the generated unit should use by-label/ instead, and warn if a label is not provided. second, if you define a mount unit manually, we could check the What

the second could live in Ignition actually

I think so, which is why this would have to live elsewhere

The label helps, but it does not resolves things for existing nodes

I'm +1 for adding docs about using labels

what is the problem for existing nodes?

Say you do a major unamed OS update from 8 to 9 and the disks are not discovered in the same order anymore

and this is because people used unstable names in their units?

note this isn't just a CoreOS problem though. we should lean on leapp there where I could see this "specialization" live

i.e. `/dev/sda6` versus `/dev/disk/by-label/my-data` ?

unfortunately the names are stable until they aren't

dustymabe: yeah, exactly

yes

If you use `/dev/disk/by-label/my-data` then you immediately have a per-node config

for the partitionning part

travier: how so? labels are generic. e.g. 'etcd-data'

the device backing them may not be

hmm. part of me feels like we should fix it - hmm or rather, maybe we should do CLHM and tell the user how to fix and maybe even give them a migration script

i'm not sure how I feel about automagically changing peoples mount units - when there might be some complicated units (i.e. we can't test everything and I don't think we should try)

agree this is risky

note I feel like this warning for the upcoming wifi removal has worked out well: ``` [dustymabe@media ~]$ ssh core@192.168.100.1 Fedora CoreOS 40.20240504.2.0 ########################################################################## WARNING: NetworkManager-wifi is a requested layered package on this system, but no Wi-Fi drivers are requested. The Wi-Fi drivers will no longer be included by default in the future. More context and remediation steps are available in the following FAQ entry: https://docs.fedoraproject.org/en-US/fedora-coreos/faq/#wifi-fw To disable this warning, use: sudo systemctl disable coreos-check-wireless-firmwares.service ########################################################################## Tracker: https://github.com/coreos/fedora-coreos-tracker Discuss: https://discussion.fedoraproject.org/tag/coreos ```

but the idea would be to provide an option for those that want to "specialize" existing installations and automatically specialize new installations

so basically we can just let people know when they have units that might be unstable and then they can either take action or disable the warning

right, we can give them instructions for how to improve their situation

I also agree that working with leapp folks would be good, but this is RHEL only afaik

MOTD seems like it'd be a good fit here indeed

Not sure if I understand this correctly but could we not mount the volumes in etc/fstab based on the uuid's?

apiaseck: yes, that's the idea, but we need to make it easier for users to set this up

travier: Jonathan Lebon, but I agree for newly provisioned systems it would be good to create mount units with more correct names if we can too

(I don't think we should solve this / take a decision in this meeting but wanted to start the discussion)

what do folks think about an MOTD for this at least?

i can file an issue against butane also to see how we can improve things there

I'm OK with that. We would also need actionable docs

yeah, we basically should audit all our docs for this IMO

and e.g. a section or at least a NOTE box on the storage page

travier: want to file a docs issue for this?

Sure, will do

i've thought about something similar to your idea about selectors before, but using udev rules to create more symlinks

there might be something there worth exploring too

👍

i'm not sure how fancy we should get :)

ok, move on to the next topic?

!link https://github.com/coreos/fedora-coreos-tracker/issues/1730

(tangentially related to this one) was the bootc one on the agenda for today?

Colin Walters: it's next in the list :)

(https://github.com/coreos/fcos-meeting-action/issues/88#issue-2310854304)

do folks want to discuss that one first instead?

If folks are there for the bootc one we could move to it?

WFM

I'm happy to talk about this one if it's ok, though travier wrote the issue

go ahead!

OK so I think as most but not all know, I used to be on this team working on coreos and have for a while now been working on doing something different, but related that landed in RHEL in https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/using_image_mode_for_rhel_to_build_deploy_and_manage_operating_systems/index

There's a lot to say here but I think all the prior discussion around device naming etc. is a good example of a mature project discussion. However I also think CoreOS is well-defined and well maintained it is also a kind of "technological peak"

All the opinions the project has also constrain where it can go and what it can do

The fedora bootc project is all about basically saying "anywhere you can dnf, you can bootc" and I hope it feels literally "more fedora/rhel" in that aspect

And it's all about going all in on containers as the technical heart of things, the center of gravity

So this issue is about rebasing FCOS on bootc technologies; there's a lot of sub-details there

A lot of ways to slice this; one for example would be that we could cease maintaining FCOS rawhide separately (things like https://github.com/coreos/fedora-coreos-config/pull/3004 ) and always maintain bootc rawhide, and just base fcos on that

Getting to using container images on the wire for updates is a huge one

So I hope we can figure out how to make incremental progress on these things

It's important to note there are *very* fundamental differences in the fedora-bootc approach vs current FCOS - especially things like the "evergreen stream" model on top of fedora, that drives things like the python bits, etc. And the general assumption users start by deriving their own container images.

I stubbed out a table here https://docs.fedoraproject.org/en-US/bootc/fedora-coreos/ that could definitely use some expansion

right. i think another way to say that latter point is that FCOS is intended to be usable as is for the most part, while fedora-bootc very likely requires derivation. and that drives so much of the UX.

Overall I hope to finally achieve what I've been trying to do for years in having a shared "base image" between all the (current ostree, hopefully future container-based) fedora variants

> And the general assumption users start by deriving their own container images. Yeah. I think this is where we differ

btw one interesting view into this is that I started by forking the FCOS docs as the bootc docs, and that was *very* enlightening as to the differences. Compare https://docs.fedoraproject.org/en-US/bootc/sysconfig-network-configuration/ with https://docs.fedoraproject.org/en-US/fedora-coreos/sysconfig-network-configuration/

I mentioned this to dusty but I thought it was cool when I realized we can actually just document `podman run fedora-bootc nm-generator` as a way to run it (which we can with FCOS too! But the fcos docs don't think about fcos-as-container)

And another side thing here is a lot of the FCOS docs are "encode these files in butane" when it's WAY more ergonomic to just document a dockerfile `COPY` instruction

I'm interested to know what benefits this group sees in the bootc approach, for instance, is the prospect of collaborating w/ other image-based Fedora variants attractive? Will it save FCOS time, etc

it'd be good to flesh out the CI story around the base images. i.e. how exactly do we share and contribute to versioned base images/image definitions. FCOS uses lockfiles right now which... definitely is a massive detail wrt the rest of Fedora both implementation-wise and conceptually

Jason Brooks: to answer your question more directly, i think i see a lot of potential benefits in sharing the workload to maintain stability

Ideally we would integrate bootc into Fedora CI and release process to be able to gate package update on bootc image working.

yes, travier that's the real value I see

one side note: a toplevel goal I have is that it's actually the fedora/centos bootc project, and we try aggressively to avoid letting docs, build system etc diverge between the two

that would already be a massive benefit to FCOS that would help us move forward with getting closer to bootc

can you elaborate on this?

travier: indeed. what i'd say is ideally we don't have lockfiles for the base images and sprint towards that gating CI instead

right now the docs describe *both* c9s and fedora:40, and we are sharing the image definitions pretty closely

ok so you were just referring to c9s and fedora:40 bootc and not referring to FCOS there?

right

hey folks

!hi

Neal Gompa (ngompa) - he / him / his

👋

if y'all don't mind, I've got a few questions here

(Note we have 2 minutes left in this meeting)

(Note: we have 2 minutes left in this meeting)

okay, then I'll make it quick

bigger picture we're obviously not going to change many things overnight; but we are spinning up more resources around this and so this will likely just become an ongoing merger/collaboration hopefully

1. with the new "image mode"/bootc/etc. stack, from the Kinoite perspective, does this mean we need a new backend to manage system updates? 2. how compatible with existing image build tools is this new stack? 3. does it _have_ to result in read-only environments?

also note for everyone that there are fedora-bootc community meetings on Tuesdays and Thursdays: https://gitlab.com/fedora/bootc/tracker#meetings

Conan Kudo: those sound like questions more for ^ :)

sure, I can take it there

yeah, probably better for tomorrow's meeting

agreed, but briefly 1) no, rpm-ostree will continue to work. 2) compat, but note a big goal of bootc (vs ostree) is to own installation; there's `bootc install to-filesystem` and we are building things up there 3) yes but you can make a transient writable overlay if you want

1) it will need one in the end

1. it will need one in the end (once we remove rpm-ostree)

ok, we're over time now. let's do a quick open floor before closing

anything anyone wants to bring up for open floor?

We'll talk about Python next week 😅

alrighty, closing in 60s

Thanks Jonathan Lebon for running the meeting :)