16:30:43 <jlebon> #startmeeting fedora_coreos_meeting
16:30:43 <zodbot> Meeting started Wed Sep 13 16:30:43 2023 UTC.
16:30:43 <zodbot> This meeting is logged and archived in a public location.
16:30:43 <zodbot> The chair is jlebon. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:30:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:43 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:48 <jlebon> #topic roll call
16:31:27 <aaradhak> .hello aaradhak
16:31:28 <zodbot> aaradhak: aaradhak 'Aashish Radhakrishnan' <aaradhak@redhat.com>
16:32:14 <dustymabe> .hi
16:32:16 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:32:34 <jlebon> #chair aaradhak dustymabe
16:32:34 <zodbot> Current chairs: aaradhak dustymabe jlebon
16:32:39 <marmijo> .hello marmijo
16:32:40 <zodbot> marmijo: marmijo 'Michael Armijo' <marmijo@redhat.com>
16:32:40 <travier_> .hello siosm
16:32:43 <zodbot> travier_: siosm 'Timothée Ravier' <travier@redhat.com>
16:32:53 <ravanelli> .hi
16:32:54 <zodbot> ravanelli: ravanelli 'Renata Ravanelli' <renata.ravanelli@gmail.com>
16:33:54 <travier> .hello siosm
16:33:55 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:34:03 <mnguyen> .hello mnguyen
16:34:04 <zodbot> mnguyen: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:34:17 <jlebon> #chair marmijo travier ravanelli mnguyen
16:34:17 <zodbot> Current chairs: aaradhak dustymabe jlebon marmijo mnguyen ravanelli travier
16:34:55 <travier> if we can start with https://github.com/coreos/fedora-coreos-tracker/issues/1569 that would be great
16:35:21 <jlebon> welcome all!
16:35:30 <jlebon> travier: i'm ok with that
16:35:34 <jlebon> starting in a sec
16:36:46 <jlebon> #topic Action items from last meeting
16:37:02 <jlebon> * ravanelli will work with Sumantro to organize it.
16:37:02 <jlebon> * dustymabe to open a tracker issue for the bash-color-prompt change
16:37:02 <jlebon> * travier to open a ticket for the bash-color-prompt package add for the change
16:37:05 <jlebon> * travier/jlebon to check the fwupd timer to make sure the motd message displayed when there are updates found works properly
16:37:26 <travier> both got done
16:37:28 <jlebon> #info jlebon checked that the fwupd motd should work fine: https://github.com/coreos/fedora-coreos-config/pull/2562#issuecomment-1710469306
16:37:36 <travier> https://github.com/coreos/fedora-coreos-tracker/issues/1567
16:37:44 <jlebon> #info travier opened https://github.com/coreos/fedora-coreos-tracker/issues/1567
16:38:20 <jlebon> for the first one, i think ravanelli has been working on it :)
16:38:34 <ravanelli> yeah, I started it already
16:38:45 <ravanelli> Inputs on https://github.com/coreos/fedora-coreos-tracker/issues/1571 are welcome
16:38:54 <ravanelli> It it the todo list for new tests
16:39:09 <jlebon> ravanelli: thanks!
16:39:12 <jlebon> ok cool, moving on to meeting tickets
16:39:22 <jlebon> #topic Add "lightly" supported platforms
16:39:26 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/1569
16:39:27 <dustymabe> ravanelli: we should probably schedule some time to go through that list and then organize people
16:39:43 <travier> I'll copy here the description from the issue:
16:39:50 <ravanelli> dustymabe: +1
16:39:59 <travier> Add a lighter process to add a new supported platform for Fedora CoreOS.
16:40:00 <travier> The idea is that for lightly supported platforms we do the Ignition and Afterburn integration work and we stop there. Notably we do not produce disk images.
16:40:00 <travier> We then document a procedure to take one of our exiting image and tweak it to get a valid disk image for the new platform.
16:40:00 <travier> This would significantly reduce the overhead of adding new platform to Fedora CoreOS while keeping it reasonably low effort for users to setup FCOS on their favorite platform.
16:40:22 <travier> PR for how that new process would look like: https://github.com/coreos/fedora-coreos-tracker/pull/1562
16:40:54 <travier> We have Hetzner and Scaleway support in progress in Ignition and Afterburn and they would immediately benefit from this shortened process
16:42:09 <dustymabe> I feel luke warm about this.
16:42:16 <jlebon> having users do the platform ID restamp is kinda hacky
16:42:29 <dustymabe> i'm actually OK with that ^^
16:42:46 <jlebon> we'd probably want to have a nice tool to wrap it all for them
16:43:09 <dustymabe> ye ole coreos-installer solves all problems
16:43:25 <travier> we could do a cosa sub command that takes a QCOW and does the switch
16:44:36 <dustymabe> I think the trickiest part of this is more related to communication
16:44:55 <travier> unfortunately, if we don't do something, the alternatives are that: no more platforms are added or we keep increasing our storage and pipeline costs
16:45:00 <dustymabe> i.e. when we have different levels of "supported" (a bad term, but I think you know what I mean)
16:45:26 <travier> the current process does not scale to more platforms / smaller / emerging platforms
16:45:45 <dustymabe> travier: i think we should offer this, but I think it should be clear what "stage" of support a platform is in.
16:46:22 <travier> agree
16:46:42 <dustymabe> and should we take a stand on if a platform should ever graduate to a higher stage
16:46:43 <jlebon> support-wise (i.e. servicing issues), it doesn't seem like the suggestion is to be any different than other platforms. is that in scope?
16:46:44 <travier> it's a proposal I had made a while before
16:46:50 <travier> having "support" tiers
16:47:20 <travier> https://github.com/coreos/fedora-coreos-tracker/issues/738
16:47:22 <jlebon> i see those as related but separate things
16:47:45 <dustymabe> for example: if we implement hetzner as lightweight platform now and someone came along later and wanted disk images and such created and maybe even uploaded as an image in the cloud - should we prevent that?
16:48:30 <travier> hum, how would we prevent people from uploading disk images?
16:48:32 <jlebon> dustymabe: i'd take it as input and see how many more people show up :)
16:48:39 <dustymabe> travier: official disk images
16:49:12 <dustymabe> i.e. we publish an AMI id today (that's an officially uploaded disk image to AWS)
16:49:21 <travier> then they would have to do the work to add it to the stream, etc.
16:49:28 <jlebon> if there's enough demand, then we probably should produce disk images
16:49:30 <dustymabe> right
16:49:50 <travier> the goal of this proposal is to not block on disk images existing to add a path to support a platform
16:49:51 <dustymabe> the question is more related to - is it the "work" part that's the concern or is it the storage costs
16:50:20 <dustymabe> if it's the work part then our end goal for all platforms would be full support showing up on website and official images uploaded to clouds
16:50:31 <travier> to me it's the "work" part as it takes someone from the team to do it as the community does not have the knowledge to do it
16:50:39 <travier> it's too much pipleine related
16:50:42 <dustymabe> but an intermediate "we've done most of the work, but not all" is a good middle ground
16:50:43 <jlebon> another path is to just recommend the generic metal image and give commands to convert to the right format and inject the ignition config
16:51:03 <jlebon> this is similar to some initiatives happening internally too
16:51:16 <dustymabe> jlebon: yeah, that's not great just because it hard bakes the ignition config
16:51:25 <dustymabe> i.e. only works for that user
16:51:40 <jlebon> dustymabe: true, but users have to run a command regardless
16:51:41 <travier> jlebon: the goal is to not embed the config
16:51:58 <travier> only once, not everytime they change their ignition config
16:52:00 <jlebon> agree it's less convenient
16:52:18 <travier> Cloud providers can do this as well if they feel like hosting the image
16:52:27 <dustymabe> ok so from what I'm gathering here, I think it would make everyone happy to make an "emerging" tier of supported platforms. where we can group these and provide docs for how to get them up and running
16:53:40 <dustymabe> i.e. if afterburn + ignition get implemented for a platform then they get promoted to "emerging" platform status and docs can get created for them
16:53:55 <dustymabe> if the pipeline work happens later then they get promoted further
16:54:42 <travier> +1
16:54:53 <travier> it does not stop us/anyone from doing the rest of the work
16:54:57 <dustymabe> exactly
16:55:14 <jlebon> +0.5 for me
16:55:18 <travier> it offers a simpler path for external contributors to add initial support for a platform
16:56:00 <travier> it's better for us if we reserve a platform id and document this than we have everyone using the metal image with hacks
16:56:26 <dustymabe> for platforms that aren't supported kexec is an option too :) https://discussion.fedoraproject.org/t/can-you-pivot-a-fedora-install-to-a-fedora-core-os-install/86546/4
16:57:14 <travier> yes, this is likely something we should document for platforms that have no userdata support
16:57:16 <dustymabe> I like it.. I think it might be a little less intimidating if there is a shorter path to success for external contributors
16:57:34 <dustymabe> obviously if they get initial success and want to improve the UX they can do the remaining steps
16:57:51 <jlebon> i'm just unsure about the UX side of this. i think ideally if we could have coreos-installer magic to do the platform ID editing, and not bust out libguestfs, that would be much better
16:58:19 <dustymabe> yeah - the various disk image formats make that problematic :(
16:58:21 <jlebon> e.g. it could be part of `coreos-installer download`, where it knows that for certain platforms, it needs to download the qemu image and do magic
16:59:26 <travier> Sounds like a good idea to me.However I want to be conscious of the amount of work we add for ourselves
16:59:55 <jlebon> the classic "doing less work requires work" :)
17:00:04 <travier> adding a few libguestfs commands is not great, but it's likely less work
17:00:28 <jlebon> it puts more requirements and complexity on users
17:00:57 <jlebon> anyway, it sounds like there's rough agreement on this. maybe we can flesh out the details in the ticket re. the actual UX?
17:01:00 <dustymabe> for some of these it would be as simple as a `virt-edit` command
17:01:12 <jlebon> travier: want to do a proposed or should i?
17:01:14 <dustymabe> but it does require the user to have installed that
17:02:07 <dustymabe> travier: do you like the "emerging" word better than "lightly supported"
17:02:24 <travier> well, my proposed is in theticket so I'll let you rephrase into something that works for you
17:02:25 <dustymabe> naming is hard
17:03:02 <travier> ok for emerging
17:04:14 <jlebon> #proposed We generally like the idea of "emerging" platforms. We will continue fleshing out the UX and communications part of it in the ticket.
17:04:25 <dustymabe> +1
17:04:29 <ravanelli> +1
17:04:44 <jlebon> +1
17:04:45 <dustymabe> honestly ignition+afterburn are two big pieces of the puzzle
17:04:54 <dustymabe> the only remaining big pieces I see are:
17:05:06 <travier> +1
17:05:09 <dustymabe> 1. mantle/kola support for booting instances in that cloud
17:05:15 <dustymabe> 2. ore support for uploading images to that cloud
17:05:29 <jlebon> #agreed We generally like the idea of "emerging" platforms. We will continue fleshing out the UX and communications part of it in the ticket.
17:05:30 <mnguyen> +1
17:05:36 <dustymabe> 3. a relationship with the cloud provider to test unbillled
17:05:47 <dustymabe> all other "pipeline" work is trivial
17:05:55 <dustymabe> it's 1. 2. 3. that are hard
17:05:59 <travier> agree
17:06:03 <dustymabe> I think gursewak is still working on kubevirt
17:06:05 <jlebon> dustymabe: +1
17:06:16 <jlebon> testing is a big part of this too actually
17:07:13 <jlebon> i guess we could do specialized CI that uses the cloud provider's tools like the user would, but having cosa/ore support would be much better
17:07:24 <jlebon> ok, let's move on
17:07:40 <jlebon> #topic New Package Request: gvisor-tap-vsock
17:07:45 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/1557
17:08:05 <dustymabe> travier: and I had a followup conversation with baude about this
17:08:20 <dustymabe> summarized in https://github.com/coreos/fedora-coreos-tracker/issues/1557#issuecomment-1716137519
17:09:56 <dustymabe> I think the TL;DR on this one is that the package will enable creating a generic network tunnel from guest<->host in hyperV/appleHV without having the user set up external networking (less clicks and or unknowns for a podman machine/desktop setup)
17:09:58 <travier> the podman team needs more tools included in Fedora CoreOS for the podman desktop use case
17:10:13 <dustymabe> so adding the package would strictly help them and not much anyone else
17:10:34 <travier> This would be a prime candidate for custom images but it's not ready
17:10:39 <dustymabe> I did list out options in the future fur them not needing this package at all
17:11:02 <travier> so I think we should add it even though we don't really want it. It's for a "popular" use case
17:11:02 <dustymabe> The most ideal being just have the passta networking stack support this use case
17:12:00 <dustymabe> travier: agree. I think in this case podman machine/desktop users are giving us quite a boost in our FCOS numbers (i.e. they represent a good part of our user base) so I'm inclined to add this package especially since there are future options to possibly no longer need it
17:12:13 <jlebon> so it's just gvforwarder and not gvproxy that they need?
17:12:34 <dustymabe> right, short term we can include the package and hack out the binary we don't need while they split the package
17:13:55 <dustymabe> ulitmately I don't think anyone/anything else would use this so we can remove it if they switch over to paasta or having the functionality in the podman binary
17:14:02 <jlebon> based on a previous community meeting, it sounds like there was agreement on including it. is the discussion now whether to include it now or wait for them to implement one of those approaches?
17:14:35 <dustymabe> i think in the previous community meeting we didn't have quite as much information as we have now - just wanted to bring it back up to make sure it didn't change anything
17:15:08 <dustymabe> my inclination would be to include it now rather than wait because they are wanting to use the hyper-v images today and they can't
17:15:19 * dustymabe notes we implemented the hyperv images for them
17:15:20 <travier> +1
17:16:02 <jlebon> seems reasonable to me
17:16:08 <jlebon> i think it's good that it's under /usr/libexec/podman
17:16:24 <dustymabe> yep
17:16:37 <jlebon> though i wonder how much drive there'd be to implement some of the other approaches once it's in
17:16:54 <dustymabe> there's always a risk there
17:17:16 <dustymabe> the way I look at it - it's kind of like letting somone borrow money
17:17:18 <travier> given that it's not in the initrd, the size issue is not an immediate problem
17:17:18 <jlebon> i think the most likely scenario is that the teams move on to other things :)
17:17:43 <dustymabe> don't expect to get paid back - if they pay you back, it's a nice surprise
17:18:22 <dustymabe> yeah - we can follow up with him more later on it to ask
17:18:22 <jlebon> right, i think it's good to be upfront about that
17:18:37 <jlebon> should we file an issue on their project to increase the odds?
17:18:50 <dustymabe> upfront/honest with ourselves :) - but we don't have to let them know we don't expect them to implement it
17:18:59 <dustymabe> jlebon: yes, I think that would be a good idea
17:19:19 <dustymabe> at least we can bump it in the future to ask of any updates on the status
17:19:48 <dustymabe> how about #action dustymabe to work with baude to open a podman issue for exploring the options mentioned in https://github.com/coreos/fedora-coreos-tracker/issues/1557#issuecomment-1716137519
17:19:50 <jlebon> option 2 would be the most desirable since it sounds like the most likely to translate into a smaller footprint
17:20:03 <dustymabe> #action dustymabe to work with baude to open a podman issue for exploring the options mentioned in https://github.com/coreos/fedora-coreos-tracker/issues/1557#issuecomment-1716137519
17:20:17 <jlebon> but i don't know the technical details there
17:20:38 <dustymabe> jlebon: right, and that involves another team (passta) - so might go smooth or not smooth
17:20:50 <dustymabe> does my action item sound good? ^^
17:21:03 <jlebon> looks good
17:21:24 <jlebon> ok, we're getting short on time, so i think i'll move straight to open floor unless one of remaining topics is urgent
17:21:31 <travier> +1
17:21:34 <jlebon> i think last time we went over and didn't really have time for open floor
17:21:41 <dustymabe> should we do an `#agreed` for this?
17:22:19 <jlebon> dustymabe: go for it :)
17:22:43 * jlebon will be back in 1 min. feel free to move to open floor
17:22:47 <mnguyen> sgtm
17:23:25 <dustymabe> #proposed as previously agreed, we will include gvisor-tap-vsock in FCOS. For now we will remove the unneeded binaries from the RPM while we wait for the package to get split. In the future the podman team will explore other options and we'll open a podman issue to track that work.
17:24:24 <dustymabe> votes?
17:24:30 * jlebon is back
17:24:41 <jlebon> +1
17:24:56 <dustymabe> #agreed as previously agreed, we will include gvisor-tap-vsock in FCOS. For now we will remove the unneeded binaries from the RPM while we wait for the package to get split. In the future the podman team will explore other options and we'll open a podman issue to track that work.
17:25:09 <dustymabe> I suspect maybe travier stepped out
17:25:19 <dustymabe> FTR I encourage everyone to vote
17:25:34 <mnguyen> +1
17:25:45 <dustymabe> jlebon open floor time
17:25:48 <jlebon> ok cool, let's move on
17:25:49 <jlebon> #topic Open Floor
17:26:02 <jlebon> anyone has anything they'd like to share?
17:26:08 <travier> +1
17:26:36 <dustymabe> ravanelli: should we try to find a time here to have a working session on the test day organization?
17:27:28 <ravanelli> sure
17:27:57 <ravanelli> I need to get some lunch after this meeting and then I'm free
17:28:28 <dustymabe> might be a little late for anyone in Europe - should we try a different day?
17:29:56 <dustymabe> what works for everyone else that might want to join?
17:30:55 <dustymabe> looks like maybe everyone left already - ravanelli let's organize in the matrix channel after our lunch
17:31:13 <jlebon> interested to join. my schedule is pretty flexible
17:31:17 <jlebon> +1 to discuss in matrix
17:31:18 <mnguyen> another day works best better for me
17:31:53 <mnguyen> i'm interested in joining
17:32:01 * jlebon will close meeting in 45s
17:32:04 <jlebon> mnguyen: +1
17:32:12 <jlebon> #endmeeting