16:30:23 <dustymabe> #startmeeting fedora_coreos_meeting
16:30:23 <zodbot> Meeting started Wed May  3 16:30:23 2023 UTC.
16:30:23 <zodbot> This meeting is logged and archived in a public location.
16:30:23 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:30:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:23 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:29 <dustymabe> #topic roll call
16:30:42 <dustymabe> .hi
16:30:45 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:52 <fifofonix> .hi
16:30:54 <zodbot> fifofonix: fifofonix 'Fifo Phonics' <fifofonix@gmail.com>
16:31:47 <gursewak> .hi
16:31:52 <zodbot> gursewak: gursewak 'Gursewak Singh' <gurssing@redhat.com>
16:32:06 <ravanelli> .hi
16:32:11 <zodbot> ravanelli: ravanelli 'Renata Ravanelli' <renata.ravanelli@gmail.com>
16:33:03 <jlebon> .hello2
16:33:08 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:33:11 <dustymabe> #chair fifofonix gursewak ravanelli jlebon
16:33:11 <zodbot> Current chairs: dustymabe fifofonix gursewak jlebon ravanelli
16:33:27 <dustymabe> i think travier is on holiday this week
16:34:13 <walters> .hi
16:34:17 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:34:22 <dustymabe> #chair walters
16:34:22 <zodbot> Current chairs: dustymabe fifofonix gursewak jlebon ravanelli walters
16:34:24 <dustymabe> welcome walters
16:34:33 * dustymabe will get started soon
16:35:01 <dustymabe> #topic Action items from last meeting
16:35:07 <dustymabe> * dustymabe to write coreos-status post about CIFS issue for f38 rebase heading to stable
16:35:17 <dustymabe> #info status post went out: https://lists.fedoraproject.org/archives/list/coreos-status@lists.fedoraproject.org/message/TXXLNI4TM22OBSOL7CS32JPLCDGBQJVO/
16:35:30 <dustymabe> and the stable F38 update is rolling out (starting today)
16:35:42 <mnguyen> .hello mnguyen
16:35:43 <dustymabe> #chair mnguyen
16:35:43 <zodbot> Current chairs: dustymabe fifofonix gursewak jlebon mnguyen ravanelli walters
16:35:46 <zodbot> mnguyen: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:36:00 <bgilbert> .hi
16:36:04 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:36:08 <dustymabe> hopefully fifofonix found all our 37->38 issues and it's smooth sailing from here on out
16:36:12 <dustymabe> #chair bgilbert
16:36:12 <zodbot> Current chairs: bgilbert dustymabe fifofonix gursewak jlebon mnguyen ravanelli walters
16:36:15 <dustymabe> thanks fifofonix
16:36:33 <fifofonix> lols
16:37:06 * dustymabe moves to next topic
16:37:12 <dustymabe> #topic New Package Request: nmstate
16:37:18 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1175
16:37:30 <dustymabe> ok I tagged this with meeting label
16:37:36 <dustymabe> we have a PR to the docs to add nmstate examples
16:37:50 <dustymabe> #link https://github.com/coreos/fedora-coreos-docs/pull/531#issuecomment-1513541709
16:38:21 <dustymabe> so we do want nmstate documentation, but my open question is now: do we want to document many ways of doing the same thing?
16:38:45 <dustymabe> i.e. should we just switch all of our docs over to using nmstate files rather than NetworkManager keyfiles?
16:39:09 <dustymabe> nmstate is still fairley new - so I wouldn't doubt if there are a few bugs lurking in there
16:39:14 <apiaseck[m]> .hello c4rt0
16:39:19 <zodbot> apiaseck[m]: c4rt0 'Adam Piasecki' <c4rt0gr4ph3r@gmail.com>
16:39:32 <dustymabe> I guess I'm just kind of torn on the right direction to go
16:39:47 <walters> dustymabe: offhand that seems unnecessary, I'd just include one example and link to their existing docs for the rest
16:40:06 <bgilbert> I'm thinking the network docs should have a single preferred approach, but we might have a secondary docs page e.g. "Configuring networking with nmstate"
16:40:08 <bgilbert> (or the other way aroud)
16:40:49 <dustymabe> walters: +1 - your suggestion could go on the page that bgilbert is suggesting?
16:41:25 <bgilbert> if there's nothing special about the nmstate examples wrt FCOS, walters approach would also work fine
16:41:48 <dustymabe> we did discuss recently with Jesse if we could have more than one level of nesting in the menubar so a "Networking" top level might be nice
16:42:32 <dustymabe> ok I think at least from what I'm hearing the answer isn't "let's throw away the keyfiles examples and document just nmstate"
16:42:33 <jlebon> nmstate looks easier to write and less error-prone, so it'd be nice to default to it
16:43:01 <dustymabe> jlebon: yeah.. maybe after some time we switch?
16:43:03 <jlebon> do we have a gap in our CI though where we're still heavily NM keyfile based?
16:43:37 <dustymabe> i.e. for now we doc AN example with nmstate and then point to their docs.. keep keyfiles primary (many examples). In the future we could flip that
16:43:55 <jlebon> dustymabe: SGTM. and we double-check CI coverage too first before swapping
16:44:04 <dustymabe> +1
16:44:14 <mnguyen> +1
16:45:03 <ravanelli> +1
16:45:13 <bgilbert> if we're planning to flip it in the future
16:45:31 <bgilbert> we should probably have a full set of examples now, rather than throwing away the ones in the PR and having to reconstruct them
16:45:51 <bgilbert> (i.e. on a secondary page)
16:45:54 <dustymabe> #proposed we will document a single or a few examples with nmstate (perhaps putting them on a secondary page and linking from the main page) and leave keyfiles as the primary documented network configuration for now.
16:46:30 <bgilbert> +1 as phrased.  that leaves room to choose the number of examples
16:46:30 <dustymabe> bgilbert: I don't think the PR is exhaustive (i.e. there isn't an nmstate example for every keyfile example)
16:46:34 <bgilbert> oh, okay
16:47:33 <dustymabe> any other votes?
16:47:44 <apiaseck[m]> +1
16:47:49 <dustymabe> there were some +1 but they came before the #proposed :)
16:47:53 <jlebon> ack
16:47:53 <mnguyen> +1
16:47:56 <ravanelli> +1
16:48:00 <apiaseck[m]> +1
16:48:07 <dustymabe> #agreed we will document a single or a few examples with nmstate (perhaps putting them on a secondary page and linking from the main page) and leave keyfiles as the primary documented network configuration for now.
16:48:17 <dustymabe> apiaseck[m]: haha multiple votes!
16:48:36 <dustymabe> ok there are a lot of topics with the meeting label - we'll see how far we can get
16:48:41 <dustymabe> #topic Ship moby-engine 23.0.x in Fedora CoreOS
16:48:46 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1476
16:49:13 <dustymabe> ok I opened this one
16:49:32 <dustymabe> i'm mainly trying to get an idea of how safe we think this major update of moby-engine may be
16:50:01 <dustymabe> I opened a PR for now to pin on the old version: https://github.com/coreos/fedora-coreos-config/pull/2394
16:50:45 <apiaseck[m]> clcbeuhbdfldljgcfivv
16:50:50 <bgilbert> apiaseck[m]: +1
16:50:58 <bgilbert> I think the answer is: we don't know
16:51:09 <bgilbert> which is what `next` is for.  maybe we push it there for a while?
16:51:25 <dustymabe> yep - that works for me
16:51:49 <dustymabe> unfortunately we don't really have a lot of ci coverage for moby-engine
16:51:51 <jlebon> we could also look at the podman tests we have and see if there are some that can be generalized to test both
16:51:58 <dustymabe> jlebon: indeed
16:52:49 <dustymabe> i'd love for that to happen
16:53:15 <dustymabe> but also wouldn't be excited about doubling our tests (resource usage)
16:53:46 <dustymabe> jlebon: I won't block on that for this, but would love for someone to volunteer to look at it (not sure if there is a current open issue anywhere)
16:54:11 <jlebon> dustymabe: yeah, i think regardless having it bake in next is a good idea
16:54:21 <dustymabe> bgilbert: maybe we try something like:
16:54:36 <bgilbert> the reality is that we ship moby-engine on a best-effort basis.  I'm +1 to more tests of course, but I don't think we should necessarily prioritize
16:55:18 <dustymabe> #proposed once this makes it into bodhi stable we will add it to our `next` stream for a period of time and gather feedback.
16:55:18 <fifofonix> fifofonix: moby-engine critical for me. i will certainly be testing in next.
16:55:34 <bgilbert> fifofonix: awesome, ty!
16:55:38 <jlebon> fifofonix: +1
16:56:00 <mnguyen> fifofonix++
16:56:03 <zodbot> mnguyen: Karma for fifofonix changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:56:14 <dustymabe> votes on #proposed ?
16:56:32 <mnguyen> +1
16:56:34 <fifofonix> +1
16:56:34 <apiaseck[m]> +1
16:56:43 <jlebon> "for a period of time" is a bit fuzzy
16:56:58 <dustymabe> jlebon: yeah. that was kind of intentional
16:57:00 <bgilbert> +1
16:57:13 <jlebon> should we say e.g. 1 month? (two next releases)
16:57:17 <dustymabe> didn't really want to commit to anything up front
16:57:32 <dustymabe> jlebon: but what if we get some middle of the road feedback?
16:57:49 <dustymabe> i.e. most everything works except this one obscure thing that there is an open issue for upstream....
16:58:02 <dustymabe> maybe we should give a lower bound
16:58:05 <jlebon> i'm describing a minimum
16:58:09 <dustymabe> ok yeah
16:58:19 <jlebon> but otherwise +1
16:58:31 <dustymabe> #proposed once this makes it into bodhi stable we will add it to our `next` stream for at least a month to gather feedback before promoting it.
16:58:39 <dustymabe> better ^^?
16:58:46 <jlebon> ack :)
16:58:48 <bgilbert> +1
16:58:51 <apiaseck[m]> That sounds better indded
16:59:02 <apiaseck[m]> s/indeded/indeed
16:59:05 <bgilbert> maybe we need pin timeouts, like test snoozes :-P
16:59:05 * dustymabe notes the new version is already in `rawhide`
16:59:13 <dustymabe> fifofonix: if you wanted to get some early early testing on it ^^
16:59:20 <dustymabe> bgilbert: :)
16:59:30 <dustymabe> #agreed once this makes it into bodhi stable we will add it to our `next` stream for at least a month to gather feedback before promoting it.
16:59:45 <fifofonix> dustymabe: i can upgrade one node to that.
16:59:54 <jlebon> semi-good news: we actually have a bunch of docker tests in kola that ran on CL but were never updated to FCOS... so that's something
17:00:01 <dustymabe> fifofonix: grab me in #fedora-coreos and we can talk about it
17:00:25 <fifofonix> dustymabe: +!
17:00:27 <dustymabe> jlebon: you better watch out or I'll use my magic fingers to #action you
17:00:50 <dustymabe> 👉
17:00:51 * jlebon ducks under table
17:00:58 <apiaseck[m]> :)
17:01:15 <dustymabe> haha - i just discovered the middle finger emoji (when searching for "finger")
17:01:36 <dustymabe> ... moving on
17:01:39 <dustymabe> #topic Regular updates for the UEFI revoked signatures database (dbx)
17:01:42 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1478
17:02:11 <dustymabe> ok this one is specifically about updating the UEFI revoked signatures database (dbx)
17:02:49 <bgilbert> dustymabe: did you get any more context about why automated dbx updates would be a bad idea?
17:02:51 <dustymabe> which isn't the same thing as the bootloader updates issue: https://github.com/coreos/fedora-coreos-tracker/issues/1468
17:02:59 <bgilbert> e.g. I certainly assume Windows does it
17:03:16 <dustymabe> bgilbert: mostly the context in https://github.com/coreos/fedora-coreos-tracker/issues/1478#issuecomment-1515017176
17:03:51 <bgilbert> "who knows what they may break" doesn't seem super-compelling.  the scope of dbx is known.
17:04:12 <bgilbert> one difference between us and e.g. Server is that we don't support dual-boot
17:04:17 <dustymabe> maybe we should invite the grub folks and justin to a meeting to discuss this topic (they have more context than I would ever hope to)
17:04:19 <bgilbert> +1
17:04:50 <dustymabe> ok
17:05:04 <bgilbert> "Fedora CoreOS: automatic updates even when inadvisable"
17:05:10 <dustymabe> #action dustymabe to invite grub and kernel folks to discuss this topic further
17:05:12 <pjones> you probably want hughsie more than you want us, since he's been handling dbx updates in fwupd
17:05:23 <pjones> (though I'm happy to join, of course)
17:05:33 * dustymabe feels like pjones has a keywork notification for "grub"
17:05:38 <dustymabe> keyword*
17:05:41 <pjones> and uefi, and ...
17:05:45 <dustymabe> welcome pjones!
17:05:49 <bgilbert> pjones: ty :-)
17:06:21 <pjones> anyway, I believe current fwupd has logic for determining the "safety" of applying dbx updates, so you probably want to investigate leveraging that.
17:06:30 <dustymabe> bgilbert: I guess one thing we could establish (probably): what are the downsides if we don't update the dbx?
17:06:51 <dustymabe> pjones: definitely, I think any solution we had here would leverage fwupd and not try to reimplement anything (IIUC)
17:07:19 <bgilbert> dustymabe: AIUI, just that Secure Boot is no longer Secure.  whether or not that matters depends on your threat model really
17:07:48 <dustymabe> bgilbert: exactly.. i.e. known bad after XYZ date wouldn't be disallowed
17:08:13 <bgilbert> which means that known bad after XYZ date could be used in a bootkit
17:08:19 <pjones> dustymabe: well, for example in the near future it'll include mitigations for https://eclypsium.com/blog/blacklotus-a-threat-coming-to-a-system-near-you/
17:08:29 <pjones> bgilbert: absolutely, yes
17:09:05 <dustymabe> fun.. ok i have an action item
17:09:11 <pjones> generally speaking we don't list these as critical issues (don't quote me on the exact phrasing, go look up the CVSS scores ;) because you basically already have to have root before you care,
17:09:35 <pjones> but the threat of persistently being rooted across a re-install is real
17:10:21 <dustymabe> ok i'll move on and see if we can get the proper people here for next time
17:10:24 <dustymabe> thanks again pjones
17:10:33 <pjones> np
17:10:42 <dustymabe> #topic GCP: add aarch64 image
17:10:48 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/1377
17:11:16 <dustymabe> The open questions here are in https://github.com/coreos/fedora-coreos-tracker/issues/1377#issuecomment-1517934348
17:11:30 <dustymabe> i.e. we have image families for GCP
17:11:58 <dustymabe> for ARM we'll need separate image family (separate from the x86_64 ones)
17:12:12 <dustymabe> 1. Should we reorganize our existing image families to mention x86_64?
17:12:19 <dustymabe> 2. Should we use the convention that GCP other image families already have of using arm64 rather than aarch64 in the image family name?
17:12:44 <dustymabe> matrix bridge having trouble?
17:12:55 <bgilbert> I found the answers in https://github.com/coreos/fedora-coreos-tracker/issues/1377#issuecomment-1517956164 compelling
17:13:17 <bgilbert> there's not really any reason not to follow GCP-specific norms
17:13:27 <bgilbert> stream metadata points to the names of the image families anyway
17:14:03 <dustymabe> bgilbert: i'm happy with that answer
17:14:23 * jlebon pushes "That was easy" button
17:14:47 <dustymabe> though I will say, if I would have thought this through more upfront (at the time GCP didn't have aarch64) I would have added amd64 to the current image family names
17:15:06 <dustymabe> as I think that would have been better
17:15:44 <jlebon> agreed. it doesn't seem worth the effort of trying to create a new family for x86 and deprecate the old one at this point
17:15:50 <dustymabe> #proposed we will leave the existing image families in place (for x86_64) and create new `-arm64` image families for the aarch64 images.
17:16:39 <jlebon> ack
17:17:01 <bgilbert> +1
17:17:17 <bgilbert> dustymabe: not sure I agree there either, actually.  we followed GCP norms
17:17:50 <dustymabe> #agreed we will leave the existing image families in place (for x86_64) and create new `-arm64` image families for the aarch64 images.
17:18:05 <dustymabe> bgilbert: well I guess it's good it doesn't matter then (because we don't own a time machine)
17:18:22 <jlebon> hehe
17:18:40 <dustymabe> #topic open floor
17:18:48 <dustymabe> anybody with anything for open floor today?
17:20:02 <dustymabe> #info The Fedora 38 rebase is landing in stable over the next few days!
17:20:04 <bgilbert> adding the new image families to stream metadata will be a code change somewhere, I guess stream-metadata-go
17:20:55 <dustymabe> bgilbert: i.e. for the new architecture?
17:21:07 <bgilbert> yeah
17:21:19 <bgilbert> just pointing it out because if we forget, nothing obviously breaks
17:21:22 <dustymabe> the image family name is in the meta.json so I don't think that's hardcoded anywhere (except maybe the pipeline)
17:21:28 <dustymabe> yeah
17:22:37 <dustymabe> #info thanks to the work by gursewak we should have kubevirt images (and docs) in the next round of FCOS releases
17:23:08 <dustymabe> gursewak++
17:23:37 <apiaseck[m]> gursewak: +1
17:23:39 <dustymabe> i'm guessing we should start processing the f39 change requests (maybe next meeting) soon
17:24:00 <dustymabe> I think some of them have implications for us
17:25:06 <bgilbert> gursewak++
17:25:06 <zodbot> bgilbert: Karma for gursewak changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:25:17 <bgilbert> gursewak: thanks for finishing that work!
17:25:35 <jlebon> sweet! gursewak++ dustymabe++
17:25:35 <zodbot> jlebon: Karma for gursewak changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:25:39 <zodbot> jlebon: Karma for dustymabe changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:26:10 <dustymabe> #endmeeting