16:30:52 <dustymabe> #startmeeting fedora_coreos_meeting
16:30:52 <zodbot> Meeting started Wed Sep 14 16:30:52 2022 UTC.
16:30:52 <zodbot> This meeting is logged and archived in a public location.
16:30:52 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:30:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:52 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:56 <dustymabe> #topic roll call
16:31:01 <dustymabe> .hi
16:31:02 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:06 <Nemric> o/
16:31:21 <spresti[m]> .hello spresti
16:31:22 <zodbot> spresti[m]: spresti 'Steven Presti' <spresti@redhat.com>
16:31:31 <lucab> .hi
16:31:32 <zodbot> lucab: lucab 'Luca BRUNO' <lucab@redhat.com>
16:31:35 <marmijo> .hi
16:31:36 <zodbot> marmijo: marmijo 'Michael Armijo' <marmijo@redhat.com>
16:32:02 <dustymabe> #chair Nemric spresti[m] lucab marmijo
16:32:02 <zodbot> Current chairs: Nemric dustymabe lucab marmijo spresti[m]
16:32:14 <aaradhak> .hi
16:32:15 <zodbot> aaradhak: aaradhak 'Aashish Radhakrishnan' <aaradhak@redhat.com>
16:33:05 <dustymabe> #topic Action items from last meeting
16:33:06 <ravanelli> .hi
16:33:07 <zodbot> ravanelli: ravanelli 'Renata Ravanelli' <renata.ravanelli@gmail.com>
16:33:14 <dustymabe> we have one action from last meeting on travier
16:33:19 <dustymabe> * travier Reach out to the podman team for the conmon-rs transition
16:33:24 <dustymabe> #chair ravanelli
16:33:24 <zodbot> Current chairs: Nemric dustymabe lucab marmijo ravanelli spresti[m]
16:33:42 <dustymabe> travier: around today?
16:34:45 <dustymabe> ok I'll re-action that
16:34:54 <dustymabe> #action travier Reach out to the podman team for the conmon-rs transition
16:35:02 <jbrooks> .hello jasonbrooks
16:35:05 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:35:12 <dustymabe> topics are a little light today
16:35:30 <dustymabe> #topic tracker: F37 Test Week
16:35:33 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1225
16:35:47 <dustymabe> we've set the test day for this cycle to be Thursday 09/22
16:35:50 <dustymabe> cc SumantroMukherje
16:36:31 <dustymabe> From last cycle we wrote up a nice checklist for how to organize a test day. It would be nice if we could find a volunteer to help organize the events around test day this time. Anyone interested?
16:37:05 <dustymabe> #info Fedora CoreOS next stream was rebased to Fedora Linux 37 content!
16:38:29 <bgilbert> .hi
16:38:30 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:38:33 <dustymabe> #chair bgilbert
16:38:33 <zodbot> Current chairs: Nemric bgilbert dustymabe lucab marmijo ravanelli spresti[m]
16:38:55 <dustymabe> bgilbert: we were just looking for volunteers to help organize the CoreOS test day for the F37 cycle
16:39:08 * dustymabe will move on to the next topic here soon
16:40:11 <dustymabe> ok looks like no takers
16:40:29 <dustymabe> I don't have any other meeting topics that are clear
16:40:34 <dustymabe> #topic open floor
16:40:40 * dustymabe brb
16:41:02 <bgilbert> dustymabe: do we want to discuss barriers for Fedora major rebases?
16:41:34 <dustymabe> yep
16:41:35 <jbrooks> dustymabe, do you have a link for the test day checklist
16:41:49 <dustymabe> jbrooks: it's in the description of https://github.com/coreos/fedora-coreos-tracker/issues/1225
16:42:14 <dustymabe> miabbott did a nice job of creating the checklist last cycle
16:42:38 <dustymabe> ok for the barriers topic - the context is in https://github.com/coreos/fedora-coreos-streams/pull/561#issuecomment-1244815916
16:43:16 <dustymabe> Our instructions in our rebase checklist tell us to create a barrier for `N-2` when we're creating the first release on `N` on a new stream
16:43:45 <bgilbert> #topic update barriers
16:43:51 <bgilbert> #undo
16:43:51 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f0df0491898>
16:43:59 <bgilbert> #topic update barriers for key rotation
16:44:02 <bgilbert> #link https://github.com/coreos/fedora-coreos-streams/pull/561#issuecomment-1244815916
16:44:14 <dustymabe> wi'll start from the top
16:44:28 <dustymabe> Our instructions in our rebase checklist tell us to create a barrier for `N-2` when we're creating the first release on `N` on a new stream
16:44:58 <dustymabe> but the instructions weren't clear enough. In the past few cycle the executor has been just creating a barrier for the first `N` release on that stream
16:45:13 <dustymabe> meaning all updates go through the first version of N on every stream
16:45:26 <dustymabe> I'm wondering if we should either:
16:45:48 <dustymabe> A. update the instructions to make it more clear that to do `N-2` (and also instruct the user to skip in cases where it's not needed)
16:46:08 <dustymabe> B. codify what we have been doing and just tell the user to make the first `N` a barrier every time
16:47:12 <dustymabe> B. has the advantage of making update paths more predictable
16:47:16 <bgilbert> I agree we should do one of those
16:47:44 <dustymabe> A. has the advantage of requiring less updates up front (most users probably will never hit the barriers created for A because they are running new enough FCOS
16:48:17 <dustymabe> A. also has the disadvantage of changing the update path for old nodes (could introduce new breakage that wasn't there previously)
16:49:37 <lucab> it looks like the last time we discussed this we decided for B. and then we effectively did A. or am I misreading this?
16:49:42 <travier> .hello siosm
16:49:43 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:49:45 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629
16:50:06 <bgilbert> we decided for A but did B
16:50:24 <lucab> oops yes sorry, I swapped them
16:50:30 <dustymabe> bgilbert: right. we decided for A in the past
16:50:34 <bgilbert> I think the only thing that's changed is that we now have experience doing B, and so there's some inertia to switching
16:51:10 <dustymabe> yep. to be clear I don't really expect a lot of problems either way; just figured we should be consistent
16:51:24 <bgilbert> in sum, A is more performant but potentially brings more risks
16:51:59 <dustymabe> also we're doing a slight variation of 1. from https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629
16:52:35 <bgilbert> uh, good point
16:52:44 <dustymabe> instead of adding the barrier to the last release of N-1 we're doing it to the first release of N
16:53:03 <bgilbert> which isn't actually fit for purpose, except that we're doing it on every rebase
16:53:54 <bgilbert> so if we switch approaches, we should be careful to avoid leaving old clients stranded
16:54:14 <dustymabe> any proposals on what we should do in the future?
16:54:24 <bgilbert> I think the automation creates a bad affordance here, since it only knows how to create barriers on newly-created releases
16:54:40 <dustymabe> does it have that limitation? why
16:54:48 <dustymabe> oh oh.. the automation
16:55:02 <dustymabe> ehh. I don't see having to hand craft a commit as such a bad thing
16:55:21 <bgilbert> I don't think it's a big deal, it's just a causal factor
16:55:53 <dustymabe> +1
16:56:47 <bgilbert> no decision we make here is permanent
16:57:07 <dustymabe> my proposal - basically let's start doing 1. from https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629 - all updates going through a major rebase will flow through the last release of FX before upgrading to FX+1
16:57:26 <bgilbert> from a Fedora perspective we're already doing an unsafe thing: upgrading from arbitrary N-1 to the first N.
16:57:38 <bgilbert> Fedora supports the opposite: upgrading from latest N-1 to arbitrary N.
16:57:47 <dustymabe> right
16:58:17 <bgilbert> of course we don't run pre/post scripts on upgrade so maybe that reduces the risk
16:58:42 <bgilbert> but option A would start upgrading from arbitrary N-1 to arbitrary N
17:00:08 <bgilbert> so, to be formal:
17:00:37 <bgilbert> C. update the instructions to add a barrier on the last release of the previous Fedora major
17:00:53 <dustymabe> +1
17:01:11 <bgilbert> I think I'd favor C.  nodes that are running every update (which is hopefully most of them) won't be affected (and are also not affected today)
17:01:21 <dustymabe> correct
17:01:38 <dustymabe> it also makes thinking about what upgrade path nodes are going to take easy to think about
17:01:58 <dustymabe> i.e. for each major version hop the nodes will go to the last release in that version before going to the next major
17:01:58 <bgilbert> C makes us compliant with Fedora packager expectations, and also the upgrade path that is tested most heavily by Fedora release engineering
17:02:31 <dustymabe> bgilbert: there is a slight flaw in that statement ^^, though
17:03:00 <bgilbert> we haven't had complaints about the extra barriers, and there's something to be said for reducing our compatibility matrix
17:03:02 <bgilbert> dustymabe: oh?
17:03:13 <dustymabe> in that we cut off a Fedora N in the middle of it's actual lifetime (i.e. 6 months versus 12 or 13)
17:03:41 <dustymabe> but in practicality, your statement is right
17:03:57 <bgilbert> that's okay.  upgrades from N-1 to N are tested during preparation for N
17:03:59 <dustymabe> i.e. it's the latest software available in N-1 at the time that N become available
17:04:04 <dustymabe> indeed
17:04:08 <dustymabe> I think we're in agreement
17:04:11 <bgilbert> +1
17:04:15 <dustymabe> want me to do a #proposed ?
17:04:17 <bgilbert> sure
17:05:15 <dustymabe> #proposed We will update our instructions to add an update barrier for the last build of N-1 when the first build/release of N happens. Basically option 1. from https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629
17:05:51 <dustymabe> if we agree on this I'll also go back and update that ticket with the discussion here
17:06:13 <bgilbert> wording clarification: we'll replace the existing barrier instructions
17:06:20 <bgilbert> (rather than adding an additional barrier)
17:06:43 <bgilbert> I assume we don't want to retroactively change the existing barriers?
17:06:45 <dustymabe> #proposed We will replace our existing barrier instructions to add an update barrier for the last build of N-1 when the first build/release of N happens. Basically option 1. from https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629
17:07:24 <dustymabe> bgilbert: I'd say leave them alone and just get the policy right for the future
17:07:47 <bgilbert> +1 to leaving them alone
17:07:56 * dustymabe votes +1 to his proposal :)
17:08:04 <lucab> +1 from my side too
17:08:15 <bgilbert> +1 to proposed
17:08:35 <dustymabe> #agreed We will replace our existing barrier instructions to add an update barrier for the last build of N-1 when the first build/release of N happens. Basically option 1. from https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631724629
17:08:54 <bgilbert> cool, thanks for the discussion
17:08:55 <dustymabe> I have a running set of changes to the rebase doc so I'll update them there
17:09:07 <dustymabe> #topic open floor
17:09:10 <lucab> I was digging through the history of barriers, and it looks like multiple people misread the N-2 instruction. So I think it's better to keep the cognitive load there low.
17:09:30 <jbrooks> dustymabe, I'll help w/ the test day
17:09:35 <dustymabe> jbrooks: nice!
17:09:58 <jbrooks> I'll follow up w/ you w/ a q or two about some of the steps
17:09:59 <bgilbert> lucab: +1
17:10:13 <dustymabe> jbrooks: We can sync up real quick right after this if you want
17:10:16 <dustymabe> jbrooks++
17:10:23 <jbrooks> cool
17:11:25 <dustymabe> ok any other topics for open floor?
17:11:40 * dustymabe will close out in a few minutes if nothing new pops up
17:12:38 <bgilbert> the disablement of serial console by default is moving again
17:12:45 <travier> I like C
17:12:47 <bgilbert> (on metal)
17:12:48 <travier> sorry I'm alte
17:12:50 <travier> late*
17:12:54 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/567
17:12:55 <dustymabe> travier: no worries
17:13:03 <travier> Found https://github.com/edgelesssys/constellation on Twitter
17:13:07 <travier> apparently they use FCOS!
17:13:17 <dustymabe> bgilbert: "moving" as in "making progress" - got it
17:13:21 <bgilbert> yup
17:13:21 <travier> (the security claims are a bit overblown but meh)
17:13:52 <dustymabe> travier: oh yeah? they use FCOS?
17:13:59 <bgilbert> the coreos-status announcement should come out later this week.  per the previously-agreed schedule, next will switch two weeks after that, and testing two months after that
17:14:06 <travier> Confidential computing-optimized node images based on Fedora CoreOS; fully measured and integrity-protected
17:14:15 <travier> https://docs.edgeless.systems/constellation/architecture/images
17:14:24 <travier> haven't been able to find out more yet
17:14:28 <dustymabe> that's pretty cool
17:14:52 <dustymabe> haha Edgeless
17:15:08 <dustymabe> We had severless... now edgeless
17:16:18 <travier> https://mobile.twitter.com/EdgelessSystems/status/1569630921036386308 > if you want to retweet from the FCOS account
17:16:33 <dustymabe> ok will close out the meeting soon.. travier you had an action item from last time that we re-actioned
17:16:33 <lucab> Interesting, https://github.com/edgelesssys/constellation-fedora-coreos-config
17:16:45 <travier> yes, still need to work on that item
17:17:35 <travier> https://github.com/edgelesssys/constellation-fedora-coreos-config/commit/4c8eafd344522696cb616f61bc03271888c479e3 :)
17:18:28 <dustymabe> kinda cool to see people building on top.
17:18:58 <dustymabe> ok I'll close out
17:19:02 <dustymabe> #endmeeting