16:29:57 <dustymabe> #startmeeting fedora_coreos_meeting
16:29:57 <zodbot> Meeting started Wed May 25 16:29:57 2022 UTC.
16:29:57 <zodbot> This meeting is logged and archived in a public location.
16:29:57 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:29:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:29:57 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:02 <dustymabe> #topic roll call
16:30:19 <dustymabe> .hi
16:30:20 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:27 <lucab> .hi
16:30:28 <zodbot> lucab: lucab 'Luca BRUNO' <lucab@redhat.com>
16:30:37 <travier> .hello siosm
16:30:38 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:31:28 <jlebon> .hello2
16:31:29 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:32:03 <dustymabe> #chair lucab travier jlebon
16:32:03 <zodbot> Current chairs: dustymabe jlebon lucab travier
16:32:08 <gursewak> .hi
16:32:09 <zodbot> gursewak: gursewak 'Gursewak Singh' <gurssing@redhat.com>
16:32:18 <miabbott> .hello miabbott
16:32:19 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:33:43 <jlebon> #chair gursewak miabbott
16:33:43 <zodbot> Current chairs: dustymabe gursewak jlebon lucab miabbott travier
16:34:04 <dustymabe> will get started in a minute
16:34:57 <dustymabe> #topic Action items from last meeting
16:35:12 <dustymabe> * dustymabe jaimelm to reach out to fedora infra about creds for pushing to `quay.io/fedora/fedora-coreos` and` quay.io/fedora/fedora-coreos-kubevirt`.
16:35:23 <dustymabe> #info dustymabe opened infra ticket to request access: https://pagure.io/fedora-infrastructure/issue/10702
16:35:32 <dustymabe> hoping to hear back from them soon
16:35:43 * dustymabe notes we still need someone to pick up the kubevirt work
16:36:24 <dustymabe> ok moving on
16:36:32 <dustymabe> #topic tracker: Rebase onto Fedora 36
16:36:40 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1101
16:36:58 <dustymabe> 34/34 tasks completed!
16:37:16 <jlebon> woohoo!
16:37:18 <dustymabe> although I know it's not 100% true because lucab had to revert cincinatti
16:37:37 <dustymabe> lucab: did we ever find the root cause of the issue there?
16:37:55 <lucab> right, I still to finish bisecting it, but I'm basically left with just the F36 bump
16:38:02 <lucab> *still need to
16:38:12 <dustymabe> +1
16:38:20 <jlebon> maybe we should split that in a separate issue if there isn't one already so we can close this one
16:38:33 <dustymabe> either way -- we're fully on Fedora 36 for all our streams and all but one of our containers we run
16:39:11 <dustymabe> jlebon: yeah, i'm letting lucab take care of it.. the container is on f35 now, which isn't EOL so we'd be OK even if he didn't get it on F36
16:39:27 <jlebon> awesome work!  and it's been pretty smooth overall
16:39:37 <dustymabe> thanks to a lot of hard work by everyone
16:39:45 <dustymabe> team++
16:39:49 <dustymabe> community++
16:39:55 <lucab> If it's ok I'll track directly in the cincinnati repo
16:40:00 <dustymabe> WFM
16:40:20 <dustymabe> i'll open up a set of tickets for F37 and close the F36 ones out most likely
16:40:51 <jlebon> tracking f37 already... the work never ends
16:41:04 <dustymabe> nope
16:41:12 <dustymabe> on to the next topic
16:41:23 <dustymabe> #topic coreos autoinstall creates huge number of xfs allocation groups
16:41:29 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1183
16:41:50 <dustymabe> ok we had previously made a decision on this one.. jlebon brought some new information to the ticket about implementation
16:42:06 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/1183#issuecomment-1130250922
16:42:52 <jlebon> yeah, i was looking at it for fun, and it turned out trickier than expected
16:43:21 <dustymabe> jlebon: was the suggestion there to do the root reprovision outside of Ignition?
16:43:54 <jlebon> one thing is that it's non-trivial to try to understand the Ignition config, so that really pushes you to evaluate the situation after Ignition disks runs
16:44:32 <jlebon> dustymabe: after Ignition, yes
16:44:44 <dustymabe> hmm
16:44:55 <jlebon> basically, the obvious point where we know for sure if we'll hit this is af xfs_growfs time
16:45:14 <jlebon> and it's not really rocket science at that point, we already have all the code we need
16:45:43 <jlebon> we just need to reorganize a bit to make it easier to reuse
16:46:31 <dustymabe> ehh.. i'm not the biggest fan of making ignition-ostree-growfs gain features
16:46:51 <dustymabe> but I guess..
16:47:15 <jlebon> i'm not either, but the alternatives might actually be worse
16:47:15 <dustymabe> it also changes the point at which we do "reprovisioning" - previously it was only handled by Ignition
16:47:31 <jlebon> not exactly
16:47:55 <jlebon> the code to save and restore the rootfs is outside the rootfs
16:48:01 <jlebon> outside Ignition*
16:48:25 <jlebon> the only bit of Ignition we're re-implementing here is the mkfs.xfs
16:48:56 <jlebon> everything else in that diff is code we already have in the transposefs script
16:50:04 <dustymabe> ok.. so you're firm in the "stick with A." camp?
16:51:42 <jlebon> i think there's no great solution, but somewhat yes.  open to re-discuss the auto-/var approach too though, which seems like that's where Colin was leaning.
16:52:22 <dustymabe> nope. I just wanted to make sure that your new found knowledge of it being tricky didn't change your mind
16:52:36 <dustymabe> ok will move to next ticket unless anyone else wants to chime in
16:52:38 <jlebon> ahh gotcha
16:53:08 <dustymabe> #topic New Package Request: qemu-user-static
16:53:14 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1088
16:54:02 <dustymabe> ok so i've noticed in the BZ that there is progress being made on the packaging qualities that we took some issue with
16:54:11 <dustymabe> #link https://bugzilla.redhat.com/show_bug.cgi?id=2061584
16:54:56 <dustymabe> so we should probably start considering more strongly inclusion (i.e. I hate to waste people's time if we decide against it anyway)
16:55:11 <dustymabe> which is why I brought this us
16:55:13 <dustymabe> up*
16:56:10 <dustymabe> so... assuming we can get the packaging in the form that we want (i.e. no python, and somewhat limited to architectures we care about) are we +1 for inclusion?
16:56:37 <jaimelm> .hello2
16:56:38 <zodbot> jaimelm: jaimelm 'Jaime Magiera' <jaimelm@umich.edu>
16:56:50 <dustymabe> #chair jaimelm
16:56:50 <zodbot> Current chairs: dustymabe gursewak jaimelm jlebon lucab miabbott travier
16:56:59 <jlebon> how commonly will this be used? it sounds like a better fit for layering IMO
16:57:18 <jlebon> the packaging work helps layering too, so it's not lost
16:57:31 <travier> given that Dan is working on it, maybe they are interested in it for podman?
16:57:44 <travier> and yes, in both cases it's useful
16:57:57 <dustymabe> right. I think they are interested in it for podman-machine in a cross arch env
16:58:49 <dustymabe> recent discussion https://github.com/containers/podman/discussions/12899#discussioncomment-2784224
16:59:43 <dustymabe> jlebon: regarding layering, it's not ready yet and will take some work to get to a point where someone can rely on it. So I'm not telling people to use it.
17:00:15 <lucab> I think the idea is to include the x86 emulators on aarch64 only, and the aarch64 emulators on x86 only, correct?
17:00:36 <dustymabe> lucab: that would be what I would think
17:00:55 <dustymabe> neal wanted other architectures, but TBH I don't think that is practical
17:01:44 <dustymabe> from comment 15
17:01:46 <dustymabe> 5.6M /usr/bin/qemu-aarch64-static
17:01:51 <dustymabe> 3.9M /usr/bin/qemu-x86_64-static
17:02:15 <lucab> I'd agree with you, at most I'd consider shipping the x86 one in all the non-x86 arches
17:02:19 <jlebon> ok so if podman starts using this, it sounds like the answer is "somewhat commonly"
17:02:23 <dustymabe> lucab: +1
17:03:04 <dustymabe> jlebon: yeah. basically think if you developers all have new macbooks (aarch64) but they are still deploying to x86_64 servers
17:03:21 <dustymabe> and using podman-machine to develop on the macbook
17:03:38 <dustymabe> but the containers they are building/dev against need to be x86_64
17:04:01 <jlebon> right, gotcha
17:04:03 <dustymabe> at least that's my understanding of the use
17:04:22 <jlebon> and the podman machine is aarch64 too, right?
17:04:39 <lucab> (I feel like they'll discover soon that this kind of emulation is slow as hell, but that's just a guess)
17:04:45 <dustymabe> the podman binary running on the mac?
17:04:56 <jlebon> the arch of the FCOS VM
17:04:56 <dustymabe> lucab: from what I hear the x86_64 emulation on the m1 macs is pretty darn fast
17:05:07 <dustymabe> jlebon: yeah the arch of the FCOS VM is aarch64
17:05:27 <dustymabe> which was part of why that team was asking us for so long about aarch64 FCOS support
17:06:19 <dustymabe> is it worth trying to make a decision/proposal today?
17:06:35 <dustymabe> I just wanted to try to get out in front of this one because I know it's coming
17:06:47 <jlebon> dustymabe: i think that's native emulation though. i'm not sure if qemu knows to leverage this under the hood
17:06:49 <lucab> dustymabe: on the m1 directly maybe yes, in this nested scenario I'm less sure
17:07:27 <jlebon> i'm guessing the obvious reason the VM itself isn't x86 is for performance?
17:07:28 <dustymabe> lucab: good point.. maybe we can glean some of that info from the discussion thread?
17:08:31 <dustymabe> or maybe they just want to increase compat with container catalog that hasn't offered aarch64 containers yet
17:08:34 <lucab> I'd say overall it's a welcome change in the packaging, let's re-evaluate once the build lands in rawhide
17:09:14 <jlebon> it feels like the podman team needs better flexibility for customizing FCOS for their specific use case
17:09:32 <jlebon> CoreOS layering might be the answer there
17:09:33 <lucab> I don't personally see any blockers in the proposed arrangement
17:09:43 <dustymabe> jlebon: yeah. I think not too distant future they will probably use coreos-layering
17:10:51 <dustymabe> but they are pushing for this now.. and I also think this can be useful outside of just their use case.. i.e. others want to run x86_64 containers (since it might not be offered for other arches) on aarch64
17:10:51 <jlebon> +1
17:11:07 <dustymabe> i'll move on to the next topic
17:11:16 <jlebon> yup, makes sense
17:11:19 <dustymabe> #topic May Edition of "This Month in FCOS"
17:11:23 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1188
17:11:31 <dustymabe> anything new here?
17:11:43 <dustymabe> lucab: you were going to add a few items for rpm-ostree and ostree releases I think
17:12:32 <lucab> ah oops yes
17:12:38 <dustymabe> do we think the grub password stuff will land this month? cc saqali
17:12:49 <dustymabe> i guess this month is almost over
17:13:20 <saqali> ahh tough question
17:13:37 <saqali> I would like to say yes, unless something unforeseen comes up
17:14:08 <dustymabe> i guess if it does land we can add a note to the ticket (if you can remember) :)
17:14:55 <saqali> Ok can di
17:14:56 <saqali> 'do*
17:14:59 <dustymabe> anything else?
17:15:07 <dustymabe> for This Month in FCOS?
17:15:48 <dustymabe> #topic KubeCon North America 2022 proposals
17:15:53 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1203
17:15:58 <dustymabe> miabbott: created this ticket last meeting
17:16:35 <dustymabe> looks like mark russell is submitting a talk about CoreOS Layering
17:17:09 <dustymabe> i might hit up dalton to see if he wants to submit the joint FCOS/tpyhoon talk with me again
17:17:18 <dustymabe> anybody else?
17:17:38 <jlebon> dustymabe++
17:17:38 <zodbot> jlebon: Karma for dustymabe changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:17:38 <miabbott> i was discussing this with some folks and while i would like to see FCOS at kubecon, i think it is a hard sell to the kubecon folks.  they want to see talks that demonstrate benefit to the CNCF projects and i don't know if we have a good story for that with FCOS
17:18:27 <miabbott> (also the deadline for kubecon na is 2 days away, so time is basically expired)
17:18:32 <dustymabe> miabbott: could be a good candidate for Rejects though (they have a whole conference dedicated to rejected kubecon talks)
17:18:53 <jlebon> heh, that's neat
17:19:08 <miabbott> there a number of other conferences sponsored by the linux foundation that we should look at, which may be a better fit - https://events.linuxfoundation.org/about/calendar/
17:19:17 <miabbott> dustymabe: neat, didn't know about the Rejects
17:19:18 <dustymabe> +1
17:19:36 <lucab> (not to kill the mood, but looking at how Kubecon EU went I have some doubts this one will realistically be in-person)
17:20:13 <dustymabe> :)
17:20:17 <dustymabe> ok let's move on
17:20:19 <miabbott> is this the rejects con you were referring to, dusty?  https://cloud-native.rejekts.io/
17:20:35 <dustymabe> miabbott: correct
17:20:45 <miabbott> 👍
17:21:16 <dustymabe> #topic open floor
17:21:30 <dustymabe> anyone with anything for open floor?
17:22:44 * dustymabe just noticed the countme data doesn't seem to be updating
17:22:49 <dustymabe> travier: did you notice this?
17:23:00 <dustymabe> last update is from 2022-05-02
17:23:07 <travier> weird
17:23:09 <dustymabe> might need to ask the team
17:23:29 <travier> will add you to the group chat
17:23:36 <dustymabe> oh yay
17:23:50 <dustymabe> ok i'll close this out and give everyone back 5 min
17:23:58 <dustymabe> oh actually
17:24:20 <dustymabe> #info video community meeting next week on 06-01-2022
17:24:34 <dustymabe> still looking for a volunteer to run it - thanks to aaradhak[m] for running it last time
17:25:13 <dustymabe> we haven't gone over our FCOS goals recently - so that will be a good one to re-visit.. I think a lot of stuff has happened over the past 4 months or so
17:25:30 <lucab> we are doing some impromptu work on sysusers at https://github.com/coreos/fedora-coreos-tracker/issues/1208
17:26:08 <lucab> (right now mostly discovering odd cases which need ironing)
17:26:16 <dustymabe> lucab: any chance we'll complete the longstanding goal that we've had to get over to sysuers for FCOS?
17:27:18 <lucab> dustymabe: not right now, but there is steady progress
17:27:33 <dustymabe> ok
17:27:36 <dustymabe> i'll stay tuned
17:27:46 <dustymabe> #endmeeting