Meeting started at 2024-04-17 16:32:01 UTC

The Meeting name is 'fedora_coreos_meeting'

.hi

!hi gursewak

Gursewak Singh (gursewak)

!hi

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

!hi

!hi jasonbrooks

No Fedora Accounts users have the @ravanelli:matrix.org Matrix Account defined

Jason Brooks (jasonbrooks) - he / him / his

!hi marmijo

Michael Armijo (marmijo)

!hi

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

!hi

None (jlebon)

!hi

Dusty Mabe (dustymabe) - he / him / his

I don't see any actions in https://discussion.fedoraproject.org/t/fedora-coreos-community-meeting-minutes-2024-04-10/112474

Alright, I'll move on to the only topic we have for today then.

looks like travier tagged it in. do you recall why?

Well, there was some changes, due to the fact that dnf5 may not be ostree aware soon and some of the work would go on dnf4.

We can not ship dnf4 anyway so meh

dnf5 "may not" be ostree aware soon ?

So there was the option of shipping microdnf right now

or wait for dnf5

the work will focus on dnf4 for now

did you mean `may`?

the compat work

no, may not

was it ever ostree aware?

"will not be made ostree aware any time soon"*

ok, I understand now

i think this one probably requires syncing with dcantrell/the dnf team

I'm currently giving bootc + dnf a try on FCOS to see where the rough edges are

I had tagged it but I don't think we need to do more than what we did right now, which is wait for dnf5 to land in F41

i think i saw something go by that the change was accepted

yes, https://pagure.io/fesco/issue/3191

i think let's hold discussions on this and sync with the dnf team first

👍️

the switch has been reverted in the past so I wouldn't be confident that this will land in F41 right now

but that's another issue

the switch has been reverted in the past so I'm not confident that this will land in F41 right now

if dnf5 isn't ostree aware, does that help us much?

It helps in the layering case to "avoid" using rpm-ostree install and the confusing logic for dnf users

It helps in the layering case to "avoid" using `rpm-ostree install` and the confusing logic for dnf users

note "ostree aware" in this context means making it useful client-side. it was always my understanding that that would take time

or rpm-ostree usroverlay + dnf install

travier: that works today

yes, we need some tests for that

yeah definitely. for the layering flow too

i'll file a tracker issue for that

!hi aaradhak

Aashish Radhakrishnan (aaradhak)

(so overall, no action, but good discussion :) )

Do we want to keep the meeting label for next time?

I don't think we need to

Got it. We don't have any other issue on our plate.

Is there anything else before I can move to open-floor?

i'd like to bring up https://github.com/coreos/fedora-coreos-tracker/issues/1652 at some point but there's still discussions ongoing there from people who know more about the platform

i think maybe next week will be good. and we can see if they want to join

but the summary is that that platform is quite messy

we might have to support parsing a subset of cloud-init in afterburn to provide a good experience

hmm

Jonathan Lebon: like to pick up SSH keys? or all of Ignition?

SSH keys and hostname, possibly other things. no Ignition

the platform basically owns the cloud-config for its own platformy purposes

the users have to manually upload image right?

yes, that's my understanding

well, i think there's a templating system

so someone could upload once, and then users can build VMs off of that template

might be an option for the users to bake in a pointer ignition config into the image they upload (using coreos-installer) and then update the https location when they want to change things

i think we can have advanced options for passing ignition configs, but again, if we want to provide a good UX, we would have to parse proxmox's cloud-config

That's not a great experience :/

travier: which part?

yeah, it's definitely not ideal. i guess it depends how much we want to care about fitting into the paradigm of that platform

modifying an image and uploading it each time you want to change the URL

but from a user's POV clicking through the UI, there's no way really to just paste in your Ignition config (or for that matter, your own custom cloud-init config for cloud-init-based images)

travier: ahh gotcha. thought you were talking about something else

travier: my suggestion was more bake a single URL into the image and then update that location anytime you want to make a change

so you don't need to upload a new image

that's one way. there's also support for custom ISOs or overriding the user-data, but they're more advanced

https://github.com/coreos/fedora-coreos-tracker/issues/1652#issuecomment-2056663210

feels hacky but could work

(this platform looks like a mess)

agreed

open floor?

how realistic would it be to ask the platform and hope for a change ?

if cloud-init UX is bad as well, that's a strong case IMO

I'm afraid that it "works" for cloud-init: https://pve.proxmox.com/wiki/Cloud-Init_Support

it seems quite fundamental to how it works, so it'd be a non-trivial change i think

travier: yes, but passing custom cloud-init data isn't really first-class AIUI

I guess maybe continue to have the discussion in the ticket and maybe by next week we can get a suggested proposal for a path forward ?

which is really surprising

it's like the expectation is that you just bring up the VM and then SSH to do your configuration

dustymabe: yeah, agree

I'll give another minute or so before I end the meeting:)