16:30:20 <dustymabe> #startmeeting fedora_coreos_meeting
16:30:20 <zodbot> Meeting started Wed May 20 16:30:20 2020 UTC.
16:30:20 <zodbot> This meeting is logged and archived in a public location.
16:30:20 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:20 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:24 <jlebon> .hello2
16:30:24 <dustymabe> #topic roll call
16:30:25 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:30:29 <dustymabe> .hello2
16:30:30 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:33 <slowrie> .hello2
16:30:34 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:30:34 <davdunc> .hello2
16:30:39 <zodbot> davdunc: davdunc 'David Duncan' <davdunc@amazon.com>
16:30:52 <cyberpear> o/
16:30:55 <cyberpear> .hello2
16:30:56 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
16:31:03 <x3mboy> .hello2
16:31:03 <zodbot> x3mboy: x3mboy 'Eduard Lucena' <eduardlucena@gmail.com>
16:31:27 <lucab> .hello2
16:31:28 <zodbot> lucab: lucab 'Luca Bruno' <lucab@redhat.com>
16:31:32 <skunkerk> .hello sohank2602
16:31:33 <zodbot> skunkerk: sohank2602 'Sohan Kunkerkar' <skunkerk@redhat.com>
16:31:38 <bgilbert> .hello2
16:31:39 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:31:52 <miabbott> .hello miabbott
16:31:53 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:32:02 <abai> .hello abai
16:32:03 <zodbot> abai: abai 'Zonggen Bai' <abai@redhat.com>
16:32:09 <cyberpear> wow, lots here today!
16:32:37 <darkmuggle> .hello2
16:32:37 <zodbot> darkmuggle: darkmuggle 'None' <me@darkmuggle.org>
16:33:07 <dustymabe> #chair slowrie davdunc cyberpear x3mboy lucab skunkerk bgilbert miabbott abai cyberpear darkmuggle
16:33:07 <zodbot> Current chairs: abai bgilbert cyberpear darkmuggle davdunc dustymabe lucab miabbott skunkerk slowrie x3mboy
16:33:12 <dustymabe> what a turnout :)
16:33:51 <dustymabe> #topic Action items from last meeting
16:34:09 <dustymabe> * lorbus to try out OKD on our `next` stream so we can work out any
16:34:10 <walters> .hello2
16:34:11 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:34:11 <dustymabe> kinks before switching `stable` to f32
16:34:13 <dustymabe> * dustymabe to create a ticket where we discuss appropriate update
16:34:15 <dustymabe> barrier approach for major upgrades
16:34:17 <dustymabe> * dustymabe to get new podman release into testing release so we can fix
16:34:19 <dustymabe> stable in next weeks releases
16:34:21 <dustymabe> #chair walters
16:34:21 <zodbot> Current chairs: abai bgilbert cyberpear darkmuggle davdunc dustymabe lucab miabbott skunkerk slowrie walters x3mboy
16:35:27 <dustymabe> #info dustymabe created a intermediate testing release with podman fix (31.20200505.2.1). That fix just landed in stable yesterday (31.20200505.3.0)
16:36:00 <dustymabe> #info dustymabe created a ticket to further the barrier discussion #480
16:36:20 <dustymabe> lorbus isn't around this week so we'll re-action that for now
16:36:30 <dustymabe> #action lorbus to try out OKD on our `next` stream so we can work out any kinks before switching `stable` to f32
16:37:03 <dustymabe> #topic meeting agenda
16:37:46 <dustymabe> we have a lot of tickets to get through today so i'll mostly just iterate through those
16:38:20 <dustymabe> if anyone has a big topic to bring up feel free to do so and I'll add it to the agenda (i.e. not something small like open floor)
16:38:44 <dustymabe> otherwise I'll start on meeting tickets in a moment
16:39:32 <dustymabe> #topic F32 rebase tracker for changes discussion
16:39:39 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/372
16:39:55 <dustymabe> we're using this ticket as an excuse to talk about Fedora 32 progress
16:40:14 <dustymabe> the last update we have on the schedule is in https://github.com/coreos/fedora-coreos-tracker/issues/372#issuecomment-631586457
16:40:52 <dustymabe> #info we decided to delay the F32 transition into `testing` until the next release cycle because of an issue where clients could get stuck in a "trying upgrade" loop https://github.com/coreos/fedora-coreos-tracker/issues/481
16:41:53 <dustymabe> so we'll shift and target the f32 transition for the next testing release (around 06/02/2020) which should propagate to stable after that (06/16/2020)
16:42:39 <dustymabe> any questions or concerns related to that OR any other f32 related things someone would like to bring up?
16:43:55 * dustymabe moves to next meeting ticket shortly
16:44:18 <dustymabe> #topic Fedora 32 samba-client-libs now pulls in Unicode data
16:44:23 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/452
16:45:15 <dustymabe> we have discussed this out of band in the past I believe, (I think with luca and jlebon)
16:45:31 <dustymabe> TL;DR we've got a new dep that's large that's coming in
16:45:55 <dustymabe> I think Luca was surprised we didn't already have the unicode data in FCOS (i.e., that something else didn't already need it)
16:46:30 <dustymabe> lucab: is that accurate ^^
16:46:38 <lucab> indeed
16:46:59 <walters> i thought ICU was for rather esoteric unicode stuff
16:47:00 <cyberpear> I wonder if it could be downgraded to a Recommends, but I'm not /that/ familiar w/ samba
16:47:08 <lucab> yes
16:47:27 <walters> e.g. glib has always carried a basic implementation, and so does golang
16:47:49 <dustymabe> up until this point we haven't worked to avoid this in f32 so are we OK with it staying (as we transition our other streams to f32)
16:47:59 <dustymabe> in the assumption that something else is going to need it in the future so we might as well
16:49:13 <cyberpear> even for Fedora Minimization objective, it'd be good to get to the bottom of the requirement
16:49:14 <jlebon> hmm, probably worth doing a quick poking around at least to see how essential it is in that package
16:49:33 <dustymabe> any volunteers to do poking :) ?
16:49:53 <dustymabe> cyberpear: how plugged in are you with the minimization objective ?
16:49:53 <cyberpear> if it's not actually needed, lets drop the dep; if it can be Recommends, let's make it so, and add a comment to the .spec file about why, for the next person who comes along
16:50:13 <cyberpear> I only follow it; there are no regular meetings, just conversations on fedora-devel
16:50:19 <cyberpear> and chatting on #fedora-devel
16:50:45 <dustymabe> cyberpear: any chance you'd be willing to do some light investigation here and report back next week?
16:50:45 <cyberpear> I send patches to .specs occasionally for reasons for Recommends, or changing deps around to make things smaller
16:51:02 <cyberpear> sure, I'll take a quick look, but again, I'm not familiar w/ samba
16:51:27 <dustymabe> cyberpear: thanks so much.. Yeah I'm not sure if we have any samba experts in the meeting here with us
16:51:33 <dustymabe> if you're here.. show yourself!! :)
16:51:58 <davdunc> I have to ask AB to tell me anything about that work.
16:52:33 <dustymabe> #action cyberpear to take a look to see if we can change the libicu dep in samba-client-libs to a recommends (#452)
16:52:41 <dustymabe> cyberpear++
16:53:02 <dustymabe> #topic update barrier approach to major upgrades
16:53:07 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/480
16:53:31 <dustymabe> this is a carryover from last meeting where we were discussing what our update barrier approach to major Fedora bumps should be
16:54:00 <dustymabe> One pertinent point that was brough up is https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-630913393
16:54:45 <dustymabe> which IIUC means we need update barriers for FedoraMajor-2 to FedoraMajor
16:55:08 <jlebon> assuming we don't already have barriers in place which satisfy this
16:55:23 <jlebon> e.g. for testing, the barrier we have ensures nodes already have f32 keys
16:55:43 <cyberpear> yeah, I'd vote for no barrier unless technically needed
16:55:44 <jlebon> for stable, we don't have a barrier, but i checked that the earliest stable release already has f32
16:55:55 <jlebon> has f32 keys*
16:56:39 <bgilbert> couldn't we retrofit those barriers?
16:57:00 <bgilbert> e.g. when F33 comes out, add a barrier from F31 to F32
16:57:05 <dustymabe> clarification to my last statement in the ticket: https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-631599416
16:57:10 <bgilbert> that way they won't affect most users, but we avoid breaking stragglers
16:57:36 <dustymabe> bgilbert: yep
16:57:44 <jlebon> i guess so. though barriers already don't affect most users, since everyone in theory should be following along
16:57:58 <bgilbert> jlebon: :-)
16:58:14 <bgilbert> with CL, people _often_ launched stale images and then immediately updated
16:58:29 <bgilbert> AWS CloudFormation is one culprit
16:58:33 <cyberpear> retrofit seems reasonable, but maybe F32 comes out, then we add barrier F30->F31
16:58:52 <cyberpear> wait, that's what u said
16:58:54 <dustymabe> cyberpear: I think that is what @bgilbert is suggesting
16:58:55 <cyberpear> (sorry)
16:58:56 <dustymabe> yep
16:59:20 <bgilbert> stale images in private clouds are another
17:00:14 <jlebon> bgilbert: yeah for sure people will do that. though feels like if you're doing that, you're probably ok with multiple reboots already :)
17:00:32 <dustymabe> ok so the current proposal (to work around the key signature issue) is to retrofit barriers for old releases ?
17:01:02 <jlebon> WFM
17:01:05 <bgilbert> jlebon: sure, +1 to multiple reboots for very old images.  just trying to avoid it for reasonably recent ones
17:01:09 <bgilbert> dustymabe: +1
17:01:14 <lucab> it sounds like a reasonable middle ground
17:02:20 <lucab> at what time do we retrofit? when doing the N+1 bump?
17:02:54 <dustymabe> ok so the two proposals are 1) make a barrier such that all Fedora major N-1 flows through the latest N-1 -> N 2) make that same barrier but only after N+1 has been released (i.e., retrofit)
17:03:07 <cyberpear> maybe only need a -3 to -2 barrier.. i.e., F33 comes out, make a F30 -> F31 barrier?
17:03:18 * cyberpear (does the very first F30 release have
17:03:37 <dustymabe> I still like 1) better but I'm OK with 2) - obviously we can revisit this in the future when f33 happens
17:03:39 <cyberpear> (does the very first F31 release have F33 keys?)
17:03:59 <dustymabe> cyberpear: no I don't think - i guess we could test that now to see if f32 has f34 keys
17:04:10 <dustymabe> I don't think they make them until rawhide starts being f34
17:04:53 <bgilbert> I'm okay adding the N-1 -> N barrier at the N+1 point.  if the image is six months stale, the extra reboot seems fine
17:05:14 <dustymabe> anyone want to advocate for 1) ? If not I'll open a #proposed for the 2) proposal
17:05:58 <jlebon> bgilbert: +1
17:06:35 <jlebon> that seems like an easy SOP to wrap our head around and not mess up :)
17:07:02 <cyberpear> +1 for retroactive barriers
17:07:05 <jlebon> i think +1 to 2) for me, though with bgilbert's suggestion
17:07:44 <dustymabe> #proposed in the interest of signing keys we'll retrofit a barrier for N-1 -> N at the N+1 point. i.e., 6 months after N came out.
17:07:53 <bgilbert> +1
17:08:01 <jlebon> +1
17:08:01 <dustymabe> how was 2) different thant what bgilbert said?
17:08:04 <lucab> +1
17:08:22 <davdunc> dustymabe: I was just trying to figure that out.
17:08:41 <dustymabe> i think they are the same - but i miss things sometimes :)
17:08:57 <bgilbert> I think they're the same, and distinct from cyberpear's suggestion of -3 to -2
17:09:00 * davdunc has the same problem. I miss things.
17:09:08 <dustymabe> bgilbert: +1
17:09:15 <jlebon> dustymabe: yeah sorry, i think i misread it as putting the barrier on f31 shortly after f32 comes out
17:10:26 <dustymabe> I'll probably try to elaborate on this a little more (with an exmaple) when I populate the ticket
17:10:38 <dustymabe> #agreed in the interest of signing keys we'll retrofit a barrier for N-1 -> N at the N+1 point. i.e., 6 months after N came out.
17:10:54 <jlebon> (though again, note that we don't actually have to add a barrier on f30 for the f32 release specifically)
17:11:06 <dustymabe> jlebon: right, because there was no f30
17:11:13 <dustymabe> so we don't need to do any barriers for now
17:11:41 <jlebon> well, testing did run f30, but we have a barrier which does what we need already
17:11:55 <dustymabe> +1
17:12:12 <dustymabe> jlebon: i'll lean on you to make a followup comment about that with some details :)
17:12:20 <dustymabe> in the ticket after I put this info into it
17:12:24 <jlebon> ack, will do! :)
17:12:48 * dustymabe skipping the NIC naming card til next week based on comments in the ticket
17:12:56 <dustymabe> #topic 2020-05-20: gather status update for Fedora Council
17:13:03 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/486
17:13:19 <dustymabe> it's that time again.. what beautiful work have we been doing ?
17:13:25 <dustymabe> here is the one from last time
17:13:42 <dustymabe> link : https://github.com/coreos/fedora-coreos-tracker/issues/450
17:14:38 <dustymabe> - the FCOS landing page now offers more rich information about each version of FCOS in our streams: https://getfedora.org/en/coreos?stream=stable
17:15:10 <lucab> do we count rpm-ostree/zincati/afterbun stuff too in there?
17:15:11 <dustymabe> did the offline work land in this cycle ?
17:15:18 <jlebon> yup, osmet landed
17:15:24 <dustymabe> lucab: I think so
17:15:30 <lucab> (ignition/coreos-installer/etc ...)
17:15:31 <dustymabe> jlebon: want to give me a blurb on that ?
17:16:11 <dustymabe> basically high level things that happened - probably want to keep it under 10 bullet points
17:16:23 <jlebon> - users can now install FCOS from the live ISO fully offline
17:16:50 <dustymabe> did the vultr stuff land this cycle ?
17:16:53 <bgilbert> - Ignition config spec 3.1.0 is now available in the testing stream
17:16:53 <jlebon> (osmet applies to PXE too of course, but it's a different shade of "offline" in that context :) )
17:17:17 <bgilbert> (FCCT support not stabilized yet; coming soon)
17:17:28 <miabbott> - enabled cloud-recommended time sync configuration for AWS, GCP, Azure
17:17:57 <bgilbert> - FCCT gained support for embedding local files and directory trees in the config
17:18:00 <dustymabe> - we now offer the option to configure static networking in the interactive live installer via NM tools (nmcli/nmtui) and have that configuration propagate into an installed sysem
17:18:17 <lucab> dustymabe: yes
17:18:57 <miabbott> dustymabe: mention something about the GCP work you've been doing?
17:19:20 <dustymabe> miabbott: yeah - most of it has been behind the scenes work (in our last update we mentioned we're now uploading to GCP)
17:19:27 <dustymabe> so not as much user facing
17:19:33 <miabbott> 👍
17:19:40 <dustymabe> i did think about it :)
17:19:59 <dustymabe> i can mention that we have a docs page for it (thanks lucab)
17:20:06 <dustymabe> - docs page for GCP
17:20:33 <bgilbert> - next stream supports re-enabling sshd password auth
17:20:59 <dustymabe> lucab: the zincati work for update windows - should we put in the next update probably ?
17:21:28 <bgilbert> - docs pages for Azure and DigitalOcean
17:21:38 <lucab> dustymabe: it's currently only on master. Same for afterburn stuff. I'll add some points once released.
17:21:48 <dustymabe> +1
17:22:01 <dustymabe> thanks all for helping identify the great work that's been going on!
17:22:38 <dustymabe> if there is any we missed here feel free to add a note to the ticket https://github.com/coreos/fedora-coreos-tracker/issues/486
17:22:43 <dustymabe> #topic open floor
17:23:47 <dustymabe> crickets 👀
17:23:49 <lucab> re. signing-keys, do we need to bump anything in coreos-installer at this point?
17:24:01 <dustymabe> good question
17:24:07 <bgilbert> ooh, let me check
17:24:08 * cyberpear has an idea
17:24:28 <bgilbert> yes!
17:24:28 <dustymabe> so right now we've been signing with the f31 key still (we have a ticket to switch robosig)
17:24:29 <bgilbert> good catch
17:24:43 <bgilbert> that should go in the SOP doc if we have one
17:25:00 <dustymabe> +1 we need an SOP
17:25:01 <jlebon> https://github.com/coreos/fedora-coreos-config#moving-to-a-new-major-version-of-fedora
17:25:10 <dustymabe> oh nice :)
17:25:14 <jlebon> :)
17:25:45 <dustymabe> bgilbert: we hard code some keys right ?
17:26:12 <bgilbert> dustymabe: we do
17:26:16 <jlebon> i think i argued at some point to just use fedora-gpgp-keys instead of embedding
17:26:24 <dustymabe> jlebon: that works on a fedora system
17:26:31 <bgilbert> #action bgilbert to PR c-i and f-c-c SOP for new signing key
17:26:35 <dustymabe> if you're running on ubuntu, not so much
17:26:51 <bgilbert> yeah, I'm still in favor of hardcoding.  explicit > implicit
17:26:55 <jlebon> but... we don't support running as a fat binary, do we?
17:27:12 <bgilbert> jlebon: ?
17:27:12 <dustymabe> jlebon: i'm not sure.. i was thinking of fcct
17:27:20 <bgilbert> `cargo install` is supported
17:27:47 <dustymabe> as always "support" deserves a `*`
17:27:52 <dustymabe> i.e., support* :)
17:28:00 <jlebon> bgilbert: ok, i think this came up a few times and it wasn't clear to me what our stance was
17:28:03 <bgilbert> `cargo install` is support*ed
17:28:14 <dustymabe> 😜
17:28:23 <cyberpear> #idea fedora-coreos-rojig.src.rpm, imports the fedora-coreos-config in Sources, then runs cosa in an rpmbuild, to result in a small rojig binary RPM, built in Koji -- then only the other artifacts than the OSTREE need be built in the external-to-compose pipeline
17:28:27 <jlebon> because we do link to stuff and call out to other stuff. but anyway, no need to linger :)
17:28:31 <cyberpear> ^ but maybe for next meeting
17:29:22 <dustymabe> cyberpear: that seems like a fun thought exercise
17:29:31 <dustymabe> definitely quite a ways from where we are now
17:29:43 <jlebon> cyberpear: that's an funky but interesting idea
17:29:58 * cyberpear loves RPMs
17:30:04 * cyberpear loves SRPMS
17:30:12 <dustymabe> meeting time is..... up.. any final thoughts before closing?
17:30:51 <walters> cyberpear: koji has this "runroot" thing which is how Fedora Atomic Host was built, and coreos-assembler was created and works the way it does in large part in result to how awful that was
17:31:32 <lucab> a related point is, we are basically re-inventing initscripts as generators in -config, and I'm scared
17:31:32 <cyberpear> I'm saying, run coreos-assembler in the RPM build, just have koji/rpmbuild run it for you
17:31:51 <walters> (Fedora Silverblue and IoT are still built that way and I'm trying to fix that)
17:32:04 <dustymabe> mock uses container tech too - so it doesn't stack well IIUC
17:32:05 <cyberpear> yeah, I've been wanting to get some/many of those moved out of fedora-coreos-config into better homes, but...
17:32:09 * cyberpear has very little bandwidth
17:32:28 * dustymabe needs to run soon
17:32:45 * cyberpear has nothing more
17:32:48 <lucab> let's close, we can move other things back to our channel
17:32:51 <dustymabe> #endmeeting