16:27:53 <dustymabe> #startmeeting fedora_coreos_meeting
16:27:53 <zodbot> Meeting started Wed Oct 27 16:27:53 2021 UTC.
16:27:53 <zodbot> This meeting is logged and archived in a public location.
16:27:53 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:27:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:27:53 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:27:59 <dustymabe> #topic roll call
16:28:04 <dustymabe> .hi
16:28:05 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:28:09 <ravanelli> .hi
16:28:10 <zodbot> ravanelli: ravanelli 'Renata Andrade Matos Ravanelii' <renata.ravanelli@gmail.com>
16:28:34 <jmarrero> .hi
16:28:35 <zodbot> jmarrero: jmarrero 'Joseph Marrero' <jmarrero@redhat.com>
16:28:38 <jdoss> .hi
16:28:41 <zodbot> jdoss: jdoss 'Joe Doss' <joe@solidadmin.com>
16:28:46 <jlebon> .hello2
16:28:47 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:29:45 <copperi[m]1> .hello copperi
16:29:46 <zodbot> copperi[m]1: copperi 'Jan Kuparinen' <copper_fin@hotmail.com>
16:29:58 <lucab> .hi
16:29:59 <zodbot> lucab: lucab 'Luca BRUNO' <lucab@redhat.com>
16:30:25 <bgilbert> .hi
16:30:26 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:31:37 <jbrooks> .hello jasonbrooks
16:31:38 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:31:47 <travier> .hello siosm
16:31:48 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:31:58 <dustymabe> #chair ravanelli jmarrero jdoss jlebon copperi[m]1 lucab bgilbert jbrooks travier
16:31:58 <zodbot> Current chairs: bgilbert copperi[m]1 dustymabe jbrooks jdoss jlebon jmarrero lucab ravanelli travier
16:32:14 <jaimelm> .hello2
16:32:15 <zodbot> jaimelm: jaimelm 'Jaime Magiera' <jaimelm@umich.edu>
16:32:38 <dustymabe> #chair jaimelm gursewak_ saqali
16:32:38 <zodbot> Current chairs: bgilbert copperi[m]1 dustymabe gursewak_ jaimelm jbrooks jdoss jlebon jmarrero lucab ravanelli saqali travier
16:32:53 <saqali> .hello
16:32:53 <zodbot> saqali: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
16:33:03 <dustymabe> good to see everyone here today.. will get started in just a moment
16:33:28 <miabbott> .hello miabbott
16:33:29 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:34:11 <dustymabe> #chair miabbott
16:34:11 <zodbot> Current chairs: bgilbert copperi[m]1 dustymabe gursewak_ jaimelm jbrooks jdoss jlebon jmarrero lucab miabbott ravanelli saqali travier
16:34:21 <dustymabe> #topic Action items from last meeting
16:34:33 <dustymabe> * dustymabe to write docs for rpi4 including updating eeprom
16:34:45 <dustymabe> re-actioning - should have a PR from me on this later this week
16:34:53 <dustymabe> #action dustymabe to write docs for rpi4 including updating eeprom
16:34:59 <dustymabe> and that's it from last time
16:35:17 <dustymabe> #topic F35: CHANGE: More flexible use of SSSD fast cache for local users
16:35:23 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/875
16:35:38 <dustymabe> looks like from travier in the ticket that we should be good to go on this for f35
16:35:57 <dustymabe> one slight issue with the integration, but it's a delay and will be fixed in f36
16:36:07 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/875#issuecomment-952867863
16:36:36 <lorbus> .hi
16:36:37 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:36:45 <dustymabe> #chair lorbus
16:36:45 <zodbot> Current chairs: bgilbert copperi[m]1 dustymabe gursewak_ jaimelm jbrooks jdoss jlebon jmarrero lorbus lucab miabbott ravanelli saqali travier
16:37:03 <dustymabe> i'll update the ticket and close it out - any objections or further discussion?
16:37:12 <walters> .hi
16:37:13 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:37:18 <dustymabe> #chair walters
16:37:18 <zodbot> Current chairs: bgilbert copperi[m]1 dustymabe gursewak_ jaimelm jbrooks jdoss jlebon jmarrero lorbus lucab miabbott ravanelli saqali travier walters
16:37:43 <travier> I think we can close it for now and we'll see if we need to make a change later. Nothing is pressing
16:38:01 <jlebon> +1
16:38:01 <dustymabe> #info the report by travier indicates we shouldn't have any issues with the "More flexible use of SSSD fast cache for local users" change
16:38:22 <dustymabe> #topic Handle re-invocations of coreos-installer on a new disk
16:38:27 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/976
16:38:48 <dustymabe> anybody want to intro this one? we discussed it in the past, but there is new information/updates?
16:39:10 <jlebon> yup, i can
16:39:32 <dustymabe> jlebon: maybe focus on what's changed since https://github.com/coreos/fedora-coreos-tracker/issues/976#issuecomment-930490695
16:39:45 <jlebon> last time I think we decided to keep chatting in the ticket before coming to a proposal
16:40:00 <jlebon> so where we are now is:
16:40:19 <jlebon> - we have code in FCOS which add boot=UUID=... for subsequent boots
16:40:35 <jlebon> - we have code pending for erroring out if multiple boot filesystems are found on first boot
16:40:50 <jlebon> what I'd like to propose is:
16:41:32 <jlebon> - add code to more strongly tie the boot filesystem to a rootfs by adding a stamp file at e.g. /boot/.rootfs-uuid
16:42:11 <jlebon> this will ensure that once we claim a boot filesystem, it can never be claimed by any other rootfs
16:43:16 <jlebon> <EOM>
16:43:34 <dustymabe> jlebon: quick question.. what did we do with all the pieces of code that mount boot by label?
16:44:06 <jlebon> dustymabe: it's all still there.
16:44:45 <jlebon> the stamp file approach makes it somewhat safe to use "retroactively"
16:45:09 <jlebon> remember after first boot, nothing really cares aboot /boot in the initrd. and the rootfs now will only mount by UUID
16:45:49 <dustymabe> ahh, so if on first boot we error if multiple boot filesystems are found - then we should be safe to mount by label
16:46:06 <jlebon> yeah, exactly
16:46:31 <dustymabe> might be worth picking apart "first boot" a bit more (considering kargs reboots and such), but yeah seems like a reasonable approach
16:47:24 <jlebon> ack cool. if there are no objections, i'll implement it
16:47:33 <lucab> I'm only a bit worried because this adds quite a bit of complexity and I have anyway seen nodes even with duplicated UUIDs, but overall I'm not against trying to tighten it
16:48:27 <dustymabe> jlebon: for "we have code pending for erroring out if multiple boot filesystems are found on first boot" - is it possible for the user to remove the 2nd disk and reboot and the system complete firstboot bringup fine?
16:48:38 <walters> duplicate uuids seems like it could happen in the case where one installs fcos version X to disk A, then try to reboot into it but end up booting back into the live iso, and installing the same version to disk B
16:48:50 <walters> i.e. they're duplicate "golden" uuids
16:48:54 <dustymabe> would kind of be sucky UX to say "we found a 2nd /boot, please do a complete re-install"
16:49:27 <dustymabe> walters: or someone makes a dd copy of a disk
16:50:00 <jlebon> i think it'd be hard/impossible to guard against bit-for-bit identical copies of the bootfs
16:50:03 <walters> so far, we're still having grub pick by label?
16:50:44 <jlebon> dustymabe: we're thinking of having coreos-installer print something as well
16:50:57 <jlebon> so at least it can be easier to catch at install time
16:51:23 <dustymabe> yeah, I guess the real question is.. does igntion get far enough on that first boot to dirty the disk (before it detects the error condition)
16:52:25 <jlebon> dustymabe: yeah, it'd happen at the very end. i'm not sure there's much we can do though, because it's possible we've been handling the wrong bootfs the whole time
16:52:38 <jlebon> (at the very end... of the initramfs)
16:53:04 <jlebon> it's tricky once you factor in devices that could take time to show up
16:53:18 <dustymabe> yeah
16:53:18 <jlebon> which is why the check is at the end. though we could also check for it at the start
16:53:25 <dustymabe> well, good to know either way
16:53:39 <dustymabe> jlebon: yeah, maybe add a check at the start
16:53:56 <dustymabe> "detected 2nd boot disk, please remove the 2nd disk and reboot"
16:53:58 <dustymabe> versus
16:54:05 <dustymabe> "detected 2nd boot disk, you must re-install"
16:54:06 <lucab> I think dustymabe made a good point, checking beforehand would have a better UX
16:54:09 <jlebon> yup, agreed
16:54:30 <lucab> I guess we have to wait for /boot anyway for the Ignition config, no?
16:54:33 <jlebon> yes, we can check at both points
16:54:45 <jlebon> even before that, multipath
16:54:47 <dustymabe> +1
16:56:30 <dustymabe> jlebon: do you want to do a #proposed ?
16:56:32 <walters> I'm still feeling long term it'd be good to get away from any dependence on labels at any point
16:57:03 <walters> in particular, in grub
16:57:18 <jlebon> #proposed we will detect multiple boot filesystems at the start and end of the initramfs. we will add a stamp file to the bootfs to ensure 1:1 binding between bootfs and rootfs.
16:58:19 <walters> +0.7 - I think this is going to help and we should do it but I think it won't be the end of the story
16:58:23 <jlebon> walters: i think we could do that for post-firstboot
16:59:01 <dustymabe> "at the start and end of the initramfs and fail if detected"
16:59:10 <dustymabe> it was implied, but might be worth spelling it out
16:59:39 <jlebon> #proposed we will look for multiple boot filesystems at the start and end of the initramfs and fail if detected. we will add a stamp file to the bootfs to ensure 1:1 binding between bootfs and rootfs.
17:00:10 <dustymabe> ack
17:00:12 <jlebon> walters: i.e. once we see there's only one bootfs, and we claim it, we also add a dropin with the UUID that the grub script sources
17:01:34 <bgilbert> ack to proposed
17:01:42 <jlebon> #agreed we will look for multiple boot filesystems at the start and end of the initramfs and fail if detected. we will add a stamp file to the bootfs to ensure 1:1 binding between bootfs and rootfs.
17:02:22 <dustymabe> nice
17:02:33 <dustymabe> jlebon: do you want to update the ticket with that outcome?
17:02:39 <jlebon> yup, will do
17:02:40 <miabbott> belated ack to proposed
17:03:52 <dustymabe> #topic Open Floor
17:04:00 <dustymabe> ok that's all the topics we had with a meeting label
17:04:23 <dustymabe> anything else we want to discuss before closing up shop?
17:04:30 <jdoss> A buddy and I are working on a Python equivalent of https://github.com/coreos/stream-metadata-go/ and a JSON schema for the metadata end point.
17:04:46 <bgilbert> jdoss: nice!
17:04:47 <jlebon> jdoss: neat!
17:04:47 <jdoss> We'll open some tickets to discuss when we get our act together.
17:05:14 <dustymabe> jdoss++
17:05:14 <walters> there is https://github.com/coreos/enhancements/pull/7 open
17:05:15 <jlebon> jdoss: once it's ready, we could house it in the coreos/ org if you're interested
17:05:22 <dustymabe> walters++
17:05:22 <zodbot> dustymabe: Karma for walters changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:05:34 <dustymabe> walters: do you think it's worth discussing that next week (video community meeting)?
17:05:46 <dustymabe> you can maybe do a short preso on it first
17:05:52 <jdoss> zodbot never gives me muh points!
17:06:14 <dustymabe> maybe I've already given you cookie's this cycle
17:06:35 <bgilbert> jdoss++
17:06:35 <zodbot> bgilbert: Karma for jdoss changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:06:37 <jdoss> jlebon: def interested in moving it to the coreos org down the road.
17:06:46 <jdoss> TIL about the one karma per person per cycle.
17:06:57 <miabbott> not sure if this was mentioned last week, but kudos to dustymabe for running a successful F35 Test Day for FCOS 🎉
17:07:14 <jdoss> Thanks Benjamin. I feel seen now.
17:07:15 <dustymabe> #info reminder about the FCOS release process surrounding Major Fedora Linux GA https://github.com/coreos/fedora-coreos-tracker/blob/main/Design.md#major-fedora-version-rebases
17:07:20 <bgilbert> jdoss: :-)
17:07:23 <dustymabe> miabbott: :)
17:07:34 <jaimelm> here, here
17:07:48 <dustymabe> thanks all who participated and thank you bgilbert for fixing the breaking bug for AWS instances before it hit stable
17:07:59 <dustymabe> and thank you jlebon for adding a test for Xen instance types in AWS
17:08:00 <jlebon> yeah, nice work all! :)
17:08:22 <bgilbert> thanks to DonaldKellett for reporting it!
17:08:54 <dustymabe> jdoss: haha - I was your first
17:09:06 <jdoss> :D
17:09:14 <dustymabe> let's throw a cookie party for jdoss
17:09:22 <jdoss> bah
17:09:26 <jdoss> I am good, I am good!
17:09:43 <miabbott> jdoss++
17:09:43 <zodbot> miabbott: Karma for jdoss changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:09:47 <dustymabe> walters: WDYT about discussing that enhancement at the video meeting next week?
17:09:55 <dustymabe> anybody with any other cool ideas for video meetings ?
17:10:20 <dustymabe> we don't always have to discuss issues.. could do something fun
17:10:35 <jdoss> https://github.com/coreos/fedora-coreos-tracker/issues/998 is so cool
17:10:38 <jaimelm> Is there anyone we would benefit from inviting to talk about? Anyone we need to network with?
17:10:57 <travier> jdoss++
17:10:57 <jaimelm> Video meetings can be good for that
17:10:58 <travier> :)
17:11:10 <dustymabe> jaimelm: yeah I imagine there's a lot of people we should start trying to coordinate with in this way
17:11:19 <lorbus> ++ to talking enhancment/7 next week!
17:11:40 <dustymabe> I know someone recently was going to start looking at how to make selinux more compatible with ostree - should probably try to get together with them
17:12:03 <jaimelm> That would be good
17:12:13 <dustymabe> jdoss: have you used quadlet? interested in first impresssions
17:12:58 <jdoss> dustymabe: it is on my list to try for sure. I write a bunch of manual systemd units for launching containers with Podman and quadlet looks fantastic to standardize things a bit.
17:13:13 <dustymabe> jdoss: I agree - i'm in the same boat
17:13:21 <dustymabe> i would have tried it already if I could package layer it
17:13:27 <dustymabe> AFAICT no RPM exists
17:13:29 <jdoss> I think I did see a tweet from dan walsh about them considering pulling it into podman.
17:13:39 <dustymabe> and the podman team is considering merging it in, yeah
17:13:41 <jdoss> maybe we should figure out if that is going to happen.
17:14:04 <dustymabe> +1
17:14:19 <dustymabe> i'll send my little jdoss bird to talk to dwalsh
17:14:21 <travier> would much prefer to have it in Go from the podman team team than C
17:14:27 <copperi[m]1> +1
17:14:50 <dustymabe> travier: :) - take that dep and make it much larger
17:15:17 <travier> dustymabe: ?
17:15:20 <lucab> what travier said, plus pre-rendering the units so that they can be version-controlled
17:15:29 <jdoss> how much more can we pack into this bikeshed
17:15:31 <dustymabe> travier: small size versus large size (files)
17:16:08 <jlebon> lucab: though there's an interesting version binding problem there. not much different than butane/ignition I guess
17:16:21 <travier> Given than it is essentially text parsing and template output, that should not be a large go binary
17:16:54 <travier> jlebon: true, what 100% sense to couple that with podman releases
17:16:59 <travier> that makes*
17:17:15 <lucab> jlebon: with systemd AND podman versions, yes
17:19:05 <dustymabe> anything else to discuss before we close up shop here?
17:19:38 <dustymabe> #info we will have a video meeting next week Nov 3rd.
17:19:56 * dustymabe is going to make travier organize one of these video meetings one day (since he suggested them)
17:20:04 <dustymabe> 😎
17:20:05 <jdoss> hah
17:20:14 <travier> dustymabe: :D
17:20:17 <dustymabe> too bad they are super late in your day
17:20:26 * dustymabe is reminded of time change
17:20:47 <travier> Yeah, better I do not organize them given that I am not sure to attend (and I won't be there next week :) )
17:21:05 <dustymabe> #info the fedora coreos meetings stick with UTC time. Regardless of what happens in your local TZ, we'll be here at 16:30 UTC
17:21:26 <copperi[m]1> :)
17:21:44 <lucab> containerized TZs, basically
17:21:50 <dustymabe> :)
17:22:05 <dustymabe> #endmeeting