16:28:43 <dustymabe> #startmeeting fedora_coreos_meeting
16:28:43 <zodbot> Meeting started Wed Sep 16 16:28:43 2020 UTC.
16:28:43 <zodbot> This meeting is logged and archived in a public location.
16:28:43 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:28:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:28:43 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:28:47 <dustymabe> #topic roll call
16:28:49 <dustymabe> .hello2
16:28:50 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:22 <jlebon> .hello2
16:30:23 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:31:05 <dustymabe> #chair jlebon
16:31:05 <zodbot> Current chairs: dustymabe jlebon
16:31:34 <skunkerk> .hello sohank2602
16:31:35 <zodbot> skunkerk: sohank2602 'Sohan Kunkerkar' <skunkerk@redhat.com>
16:31:56 <bgilbert> .hello2
16:31:58 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:32:19 <darkmuggle> .hello2
16:32:20 <zodbot> darkmuggle: darkmuggle 'None' <me@muggle.dev>
16:32:31 <dustymabe> #chair skunkerk bh7cw bgilbert darkmuggle
16:32:31 <zodbot> Current chairs: bgilbert bh7cw darkmuggle dustymabe jlebon skunkerk
16:32:55 <lucab> .hello2
16:32:55 <zodbot> lucab: lucab 'Luca Bruno' <lucab@redhat.com>
16:32:59 <dustymabe> #chair lucab
16:32:59 <zodbot> Current chairs: bgilbert bh7cw darkmuggle dustymabe jlebon lucab skunkerk
16:33:23 <ravanelli> .hello2
16:33:24 <zodbot> ravanelli: Sorry, but you don't exist
16:33:34 <dustymabe> zodbot how rude :(
16:33:59 <dustymabe> ravanelli: do you have a fedora account system account?
16:34:31 <ravanelli> No I don't =/
16:34:41 <dustymabe> ahh, that's why it doesn't have the link :)
16:35:02 <dustymabe> ping me after the meeting and I can show you how to set one up (if you want one)
16:35:14 <dustymabe> #chair ravanelli
16:35:14 <zodbot> Current chairs: bgilbert bh7cw darkmuggle dustymabe jlebon lucab ravanelli skunkerk
16:35:19 <dustymabe> #topic Action items from last meeting
16:35:30 <dustymabe> looks like the meeting last week was a bit light. no action items!
16:35:52 <dustymabe> i told jlebon to assign a bunch of work, but he was nice
16:36:03 <cyberpear> .hello2
16:36:04 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
16:36:12 <dustymabe> #chair cyberpear
16:36:12 <zodbot> Current chairs: bgilbert bh7cw cyberpear darkmuggle dustymabe jlebon lucab ravanelli skunkerk
16:36:26 <ravanelli> Thanks, I will
16:36:54 <dustymabe> #topic F33 rebase rpmdb migration
16:36:57 <jlebon> dustymabe: you did? i might have missed that :)
16:37:03 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/609#issuecomment-688977962
16:37:21 <dustymabe> jlebon: 😄
16:37:40 <dustymabe> jlebon: do you want to introduce this topic?
16:37:44 <jlebon> sure
16:37:55 <jlebon> so in f33, the default rpmdb is changing from berkeley db to sqlite: https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb
16:38:44 <jlebon> and the change proposal works well on traditional systems (they have a systemd service which does the conversion)
16:39:10 <jlebon> but it clashes with the OSTree model
16:39:45 <cyberpear> has it been tested as not working? does F32 support sqlite even if not default? is it just the conversion that needs done?
16:39:52 <walters> right among other things, ostree wants to say "the filesystem has *this* cryptographic checksum" and so a systemd service that goes and mutates it breaks that
16:39:59 <jlebon> anyway, the bottom line is: users with layered pkgs will fail to rebase from f32 to f33
16:40:15 <walters> cyberpear: i don't know why but f32 rpm indeed does not even support sqlite
16:40:31 <dustymabe> walters: ^^ that's the question I was going to ask
16:40:39 <jlebon> so the proposal is to stick with bdb for at least the first f33 release
16:40:56 <cyberpear> seems strange there's no overlap release
16:40:58 <walters> actually if it *did* then before the rpm-ostree change it would actually have changed the default and broke at least the rhcos builds
16:41:02 <jlebon> so that librpm then knows how to read both
16:41:52 <dustymabe> jlebon: yeah I think that sounds fair
16:42:10 <dustymabe> i'd even say let's stick with it for longer and then make the transition in a period of "low change"
16:42:45 <jlebon> well, whenever we do the switchover, we'll want to make the last bdb release a barrier
16:42:55 <dustymabe> correct
16:42:58 <dustymabe> that makes sense to me
16:43:01 <dustymabe> here's a question
16:43:16 <dustymabe> hypothetical:
16:43:27 <dustymabe> - i'm on f32 fcos
16:43:32 <lucab> jlebon: is the barrier technically to ensure rpm-ostree support the new format?
16:43:36 <jlebon> since it's not high priority to change over, we could just bundle it with another barrier we need to create anyway (or just create one regardless after some time)
16:43:49 <dustymabe> - i go through a f33 barrier
16:44:00 <jlebon> lucab: correct. more specifically rpm
16:44:04 <dustymabe> can I roll back?
16:44:25 <jlebon> the rpmdb is part of the OSTree commit, so it should be fine
16:44:41 <dustymabe> ok
16:44:55 <cyberpear> agreed on keeping bdb maybe half of F33 cycle, to allow things to settle before a barrier
16:44:59 <dustymabe> I guess that raises another question about barriers and rolling back
16:45:30 <dustymabe> which is if we go through a barrier, we're doing more than one transaction, which means "bye bye original deployment"
16:45:38 <dustymabe> and your ability to go "all the way back" with it
16:46:51 <dustymabe> do I understand that correctly?
16:47:15 <jlebon> you can always redeploy a version too
16:47:36 <jlebon> but yeah, barriers in general imply that you're not manually fiddling too much with updates
16:47:40 <dustymabe> yeah, though your layered packages are kind of *poof*
16:48:00 <jlebon> why?
16:48:17 <dustymabe> because they depend on the time when they were layered
16:48:20 <cyberpear> maybe make the final F33 release the barrier and only switch right before 34? ... does 34 remove bdb entirely?
16:48:37 <lucab> (you can do a lot of nasty things manually, we are not trying to save the users from themselves but to make the happy path of automated upgrades safer)
16:48:49 <jlebon> dustymabe: ahh in that sense yeah. though i guess that'll be fixed soon with your work :)
16:49:14 <jlebon> cyberpear: f34 makes it read-only
16:49:17 <dustymabe> jlebon: right, it won't be the exact same set of layered packages you had before, but you will at least be able to layer them
16:49:55 <dustymabe> jlebon: we could try to keep some sort of layered packages history and point rpm-ostree at a history entry and have it try to recreate that deployment
16:50:05 <dustymabe> i'll call myself out for going down a rat hole
16:50:06 <jlebon> dustymabe: to confirm, this isn't specific to this discussion, right? just update barriers in general?
16:50:11 <dustymabe> yep
16:50:14 <jlebon> yup +1
16:50:20 <dustymabe> ok so i'll make a proposal
16:51:07 <dustymabe> #proposed we'll keep bdb for the rpm database for at least the first release of Fedora 33 and then make the transition with a barrier in the fedora 33 timeframe
16:51:23 <jlebon> ack
16:52:09 <dustymabe> any others want to weigh in ?
16:52:29 <lucab> SGTM
16:53:20 <dustymabe> #agreed we'll keep bdb for the rpm database for at least the first release of Fedora 33 and then make the transition with a barrier in the fedora 33 timeframe
16:53:47 <dustymabe> jlebon: so we'll need to make that change when we switch to f33
16:53:59 <dustymabe> and then we'll need a tracking ticket for the barrier release that we do later on
16:54:12 <dustymabe> can you create at least the tracking ticket?
16:54:24 <jlebon> yup sure
16:54:45 <jlebon> just need to get the new rpm-ostree release into cosa
16:55:09 <dustymabe> #action jlebon to create a tracking ticket to move the rpm database from bdb to sqlite in a barrier release in the f33 time frame
16:55:42 <lucab> jlebon: just wondering, can we do that even before rebasing to F33?
16:56:13 <lucab> jlebon: that is, is a bump of the internal dependency of rpm-ostree enough?
16:56:54 <jlebon> lucab: yeah that's where i was going. we can have the bit in place even before the rebase. it should just be a "no-op"
16:57:28 <jlebon> yeah, it's purely a server-side compose thing
16:57:55 <lucab> so we could theoretically have the barrier before the first F33
16:58:37 <dustymabe> lucab: I don't think so
16:58:51 <dustymabe> the bits we need are the ability to specify which db to use
16:58:59 <dustymabe> which we can land in rpm-ostree in f32
16:59:06 <lucab> (just gauging how many degrees freedom there are)
16:59:18 <dustymabe> but the ability to read the sqlite db won't happen until we build rpm-ostree in f33
16:59:20 <dustymabe> IIUC
16:59:38 <dustymabe> well, until we get the rpm from f33
17:00:12 <jlebon> yup, exactly
17:00:34 <dustymabe> so we can land a setting that says "use bdb" in f32 (since support for bdb already exists and it is the default it is a NOOP)
17:01:01 <lucab> ack (the embedded libdnf is the thing confusing me)
17:01:02 <dustymabe> but when we get to f33 the setting that says "use bdb" will not be a NOOP
17:01:11 <dustymabe> +1
17:01:16 <dustymabe> #topic ad-hoc testing stream release to update the kernel
17:01:47 <dustymabe> we're planning to do an ad-hoc testing stream release to update the kernel to fast track a recent CVE https://bugzilla.redhat.com/show_bug.cgi?id=1875699
17:02:11 <dustymabe> but there is an existing kernel bug that affects NFS mounts that we're waiting to see if it can land in our Fedora kernels first
17:02:19 <dustymabe> this is bug https://bugzilla.redhat.com/show_bug.cgi?id=1873720
17:03:26 <dustymabe> mostly an FYI - we can move to open floor unless anyone else has topics they would like to bring up
17:04:12 <dustymabe> #topic open floor
17:04:17 <dustymabe> anybody with anything for open floor?
17:05:06 <dustymabe> #info the fedora archive repo is in place, currently just waiting on infra team to create a fedora URL to front it rather than an aws.s3 URL, which will allow us to move it in the future if we need to.
17:05:41 <jlebon> dustymabe: niiice
17:05:46 <dustymabe> jlebon: the rpm-ostree release will finish the other half of the problem too ^^ ?
17:05:56 <jlebon> yup indeed
17:06:01 <dustymabe> and then we'll just need to get the nfs package fixed
17:06:06 <dustymabe> and we'll be good to go
17:06:25 <jlebon> and add the repo to FCOS, silverblue, and IoT
17:06:57 <dustymabe> correct, the plan is to make it a subpackage of fedora-repos and we'll just install that rpm on the distros that care to solve the problem
17:07:08 <jlebon> this might be worth raising this on devel too
17:07:27 <jlebon> it's a really nice win
17:07:48 <lucab> yay!
17:07:49 <jlebon> and unblocks other stuff like slowering the Silverblue cadence
17:08:06 <jlebon> slowing*
17:08:42 <dustymabe> yep.. speaking of silverblue - this caught my eyehttps://github.com/fedora-silverblue/issue-tracker/issues/73
17:08:50 <dustymabe> https://github.com/fedora-silverblue/issue-tracker/issues/73
17:08:58 <dustymabe> looks like a problem we'll probably hit with FCOS too
17:09:18 <dustymabe> basically it looks like when someone runs sudo it tries to `mkdir /sudo` and that fails
17:09:33 <dustymabe> because on OSTree systems `/` is immutable (by design)
17:10:38 <jlebon> wait, sudo itself is trying to run `mkdir /sudo`?
17:10:49 <dustymabe> jlebon: that's what I gather
17:10:57 <dustymabe> I don't have a system up to test it on though
17:11:03 <cyberpear> why would it do that? wouldn't that fail when becoming non-root user?
17:11:07 <jlebon> that'd be... wow
17:11:35 <dustymabe> yeah, maybe I read it wrong :)
17:11:48 <lucab> the fix for that is clearly to change it to run  `sudo mkdir /sudo` instead
17:11:55 <misc> lucab++
17:11:55 <zodbot> misc: Karma for lucab changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:12:04 <dustymabe> haha
17:12:11 <dustymabe> miscbot is here
17:12:25 <jlebon> added a link to that from the tracker issue
17:12:49 <dustymabe> anything else for open floor?
17:13:38 <dustymabe> will close out the meeting in 60s
17:14:45 <dustymabe> #endmeeting