16:30:08 <jlebon> #startmeeting fedora_coreos_meeting
16:30:08 <zodbot> Meeting started Wed Mar  1 16:30:08 2023 UTC.
16:30:08 <zodbot> This meeting is logged and archived in a public location.
16:30:08 <zodbot> The chair is jlebon. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:30:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:08 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:12 <jlebon> #topic roll call
16:30:48 <dustymabe> .hi
16:30:49 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:09 <ravanelli> .hi
16:31:10 <zodbot> ravanelli: ravanelli 'Renata Ravanelli' <renata.ravanelli@gmail.com>
16:31:13 <jlebon> #chair dustymabe ravanelli
16:31:13 <zodbot> Current chairs: dustymabe jlebon ravanelli
16:31:17 <c4rt0> .hi apiaseck
16:31:18 <zodbot> c4rt0: c4rt0 'Adam Piasecki' <c4rt0gr4ph3r@gmail.com>
16:31:39 <gursewak> .hi
16:31:40 <zodbot> gursewak: gursewak 'Gursewak Singh' <gurssing@redhat.com>
16:31:40 <jlebon> #chair c4rt0
16:31:40 <zodbot> Current chairs: c4rt0 dustymabe jlebon ravanelli
16:31:47 <jlebon> #chair gursewak
16:31:47 <zodbot> Current chairs: c4rt0 dustymabe gursewak jlebon ravanelli
16:34:30 <jlebon> small group today :)
16:36:14 <jlebon> ok let's get started and see what we can accomplish
16:36:20 <jlebon> #topic Action items from last meeting
16:36:28 <jlebon> -ENOENT
16:36:58 <jlebon> #topic tracker: Fedora 38 changes considerations
16:37:03 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/1357
16:37:17 <jlebon> dustymabe: want to go over the new items?
16:37:57 <dustymabe> yeah. there are a number of things that dropped out of Fedor 37
16:38:01 <dustymabe> Fedora 38
16:38:10 <dustymabe> I assume because the change didn't make it in before branching
16:38:32 <dustymabe> but there are a few new items
16:38:44 <spresti[m]> .hello spresti
16:38:45 <zodbot> spresti[m]: spresti 'Steven Presti' <spresti@redhat.com>
16:38:53 <jlebon> #chair spresti
16:38:53 <zodbot> Current chairs: c4rt0 dustymabe gursewak jlebon ravanelli spresti
16:38:55 <dustymabe> I think it's mostly 231 232 233
16:39:07 <dustymabe> subtopic 231. cups-filters 2.0b
16:39:20 <dustymabe> #info we don't ship cups, shouldn't affect us
16:39:24 <jlebon> +1
16:39:33 <dustymabe> subtopic 232. IoT Simplified Installer]
16:39:42 <dustymabe> #info this is specific to Fedora IoT
16:39:53 <dustymabe> subtopic 233. Update python-packaging to version >= 22
16:39:57 <dustymabe> #info we don't ship python
16:40:18 <jlebon> it relates to CoreOS in that it's a consumer of coreos-installer
16:40:38 <dustymabe> oh.. for 232?
16:40:44 <dustymabe> I didn't realize that relationship
16:41:04 <jlebon> so nothing we need to adapt in FCOS, but it's something to be aware of when discussing coreos-installer enhancements
16:41:14 <jlebon> yup
16:41:25 <dustymabe> cool
16:41:28 <dustymabe> thanks for bringing that up
16:41:59 <dustymabe> jlebon: maybe we should go through the ⚠️ items
16:42:18 <jlebon> dustymabe: sounds good
16:42:39 <jlebon> #topic rawhide: upgrades fail with new openssh-9.0p1-10.fc38.1
16:42:43 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/1394
16:42:57 <jlebon> this relates to change 118.
16:43:27 <jlebon> dustymabe: want to tackle that one?
16:43:27 <dustymabe> indeed
16:43:57 <dustymabe> I think we mostly have the update in https://github.com/coreos/fedora-coreos-tracker/issues/1394#issuecomment-1446828630
16:43:59 <bgilbert> .hi
16:44:00 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:44:05 <jlebon> #chair bgilbert
16:44:05 <zodbot> Current chairs: bgilbert c4rt0 dustymabe gursewak jlebon ravanelli spresti
16:44:14 <jlebon> indeed
16:44:16 <dustymabe> @travier @jlebon and I discussed this last week. The two options we discussed were:
16:44:24 <dustymabe> 1. We roll out the changes early in Fedora 37, including an external execStartPre script for sshd that would detect non-conforming permissions and sleep for a period of time. The benefit of doing this is that after the sleep the user can still log in to the system. The negative of doing this is that it's more complex (and more work) and we could also somehow inject error if we don't test
16:44:26 <dustymabe> comprehensively enough.
16:44:30 <dustymabe> 2. We go with the migration shipped by the RPM (we're working on an update to it to make it more palatable) and give users plenty of warning with a coreos-status post.
16:45:39 <dustymabe> we were leaning towards 2.
16:46:12 <jlebon> interested in bgilbert's thoughts
16:46:28 * dustymabe is reminded that we need to make further updates and test https://src.fedoraproject.org/rpms/openssh/pull-request/39 so the maintainer can then merge it
16:46:54 <jlebon> btw, another con of 1. is that it breaks host key signing
16:47:48 <dustymabe> jlebon: couldn't we technically rollout the permissions (setgid) change to that binary too?
16:47:48 <jlebon> well, i guess we would not do it on systems where we detect it
16:48:33 <jlebon> dustymabe: i think so
16:49:35 <jlebon> hmm, yeah that could be a nice path. so then the main downside is it's more work
16:50:09 <dustymabe> well, it's more work and we could get it wrong too
16:50:15 <dustymabe> :)
16:50:34 <dustymabe> i'm OK with either path, but am a bit gassed when it comes to "extra effort" things right now
16:50:51 <bgilbert> yeah, I think I'd lean option 2 to reduce effort
16:51:06 <jlebon> +1
16:51:20 <bgilbert> also, doesn't option 2 benefit other rpm-ostree-based editions more?
16:51:40 <dustymabe> bgilbert: we have to do option 2 anyway
16:51:47 <bgilbert> okay
16:51:52 <dustymabe> i.e. we need to get that PR tested and merged
16:52:27 <dustymabe> i guess the difference between the two options here is: "do we do something extra to try to prevent users from getting locked out in a worst case scenario"
16:53:23 <jlebon> right, even if we get something wrong in 1, it wouldn't break sshd
16:53:44 <dustymabe> well. it depends on how wrong we got it :)
16:54:49 <jlebon> sure, i think we'd have to mess up harder to break it entirely :)
16:55:06 <jlebon> anyway, cool with 2. though still feeling uneasy about it
16:55:36 <dustymabe> #proposed?
16:56:52 <jlebon> #proposed we will go with option 2, where we will rely on an updated migration service shipped by sshd that works on OSTree-based systems and give a heads up on coreos-status
16:57:06 <dustymabe> +1
16:58:11 <jlebon> anyone else? bgilbert?
16:58:13 <bgilbert> +1
16:58:26 <jlebon> #agreed we will go with option 2, where we will rely on an updated migration service shipped by sshd that works on OSTree-based systems and give a heads up on coreos-status
16:58:28 <dustymabe> now - to split up the remaining work :)
16:59:04 <jlebon> dustymabe: maybe we can discuss that OOB?
16:59:04 <dustymabe> we need to get the RPM update finished/merged (preferrably before beta goes out so it can get wide testing for all of FEdora)
16:59:12 <dustymabe> and we need someone to do the status post
16:59:38 <dustymabe> jlebon: WFM
16:59:48 <jlebon> +1
17:00:02 <jlebon> #topic F38 Change: Shorter Shutdown Timer
17:00:05 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/1404
17:00:43 <dustymabe> looks like maybe we are on our own here?
17:00:55 <jlebon> travier opened an MR in https://src.fedoraproject.org/rpms/fedora-release/pull-request/249 for keeping the previous default in FCOS
17:00:58 <dustymabe> pinged mhayden and davdunc in the ticket to see what they thought
17:01:40 <pboy> Just as an info: We (server) are still discussing
17:02:04 <jlebon> pboy: +1
17:02:09 <dustymabe> pboy: good to know
17:02:21 <dustymabe> pboy: any short summary?
17:02:28 <jlebon> i guess we can get that MR merged for now and other editions can apply the same change in follow-ups?
17:02:35 <pboy> My tendency is to keep the default
17:02:52 <pboy> Some are for shorter timeout.
17:03:25 <dustymabe> pboy: yeah, the default is nice
17:03:41 <pboy> Collin Walters argments espresses my concerns.
17:03:45 <dustymabe> i just with the default was only changed for "desktop like editions" where the value is greatest (IMO)
17:03:57 <dustymabe> s/with/wish
17:04:46 <dustymabe> pboy: indeed
17:05:30 <dustymabe> I guess we can agree to try to get the PR merged and the RPM built so we can include it?
17:05:32 <dustymabe> jlebon: ^^
17:05:32 <walters> it'd be cool if we had a way to structure operating systems with like a core and derived things from it
17:06:21 <jlebon> dustymabe: WFM. want to try a #proposed?
17:06:25 <walters> (and not, for example also try to make boots prettier for desktop systems by wedging a systemd unit into grub in the core grub package)
17:06:44 <dustymabe> jlebon: go for it if you don't mind
17:07:32 <jlebon> #proposed we will get the fedora-release MR merged which currently only affects FCOS for now so that we can include it and verify it
17:08:03 <dustymabe> +1
17:08:41 <jlebon> #agreed we will get the fedora-release MR merged which currently only affects FCOS for now so that we can include it and verify it
17:08:56 <jlebon> dustymabe: did you want to talk about https://github.com/coreos/fedora-coreos-tracker/issues/1350 ?
17:09:59 <dustymabe> it's been on our list for a while to discuss. I think we maybe want to wait until we have more people here to discuss.. but maybe we have enought today?
17:10:06 <dustymabe> it's certainly not urgent
17:10:45 <dustymabe> we could also just discuss it and give a preliminary summary
17:10:50 <jlebon> good either way
17:10:55 <jlebon> sure
17:11:02 <jlebon> #topic evaluate inclusion of GPU firmware
17:11:05 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/1350
17:12:19 <jlebon> dustymabe: go for it :)
17:12:58 <dustymabe> jlebon: I think the TL;DR is that the gpu firmware got broken out into their own subpackages
17:13:08 <dustymabe> and we lost them from FCOS for a period of time
17:13:23 <dustymabe> we agreed to add them back, but also agreed to discuss in the future if we should remove them
17:13:31 <dustymabe> i.e. space savings
17:14:06 <dustymabe> i think my current stance is that it's more work to remove them than it is to leave them in so let's just leave them in
17:14:21 <dustymabe> well. I guess maybe it's not a lot of work to remove them
17:14:51 <dustymabe> but we would have to make sure things are communicated properly and provide people with "here's how to do it now" type of docs
17:15:06 <jlebon> i think the work to remove them lies mostly in evaluating the impact to users
17:15:12 <dustymabe> i think the case we hit when they got removed was some GPU processing workloads stopped working
17:16:49 <dustymabe> anybody with any other thoughts on this?
17:17:04 <jlebon> maybe we should keep them until we have container layering working well and documented?
17:17:28 <dustymabe> jlebon: that could be part of the proposed "re-evaluate in future when..."
17:17:34 <bgilbert> if we historically shipped them, and we have users using them, I'm not sure it's worth the effort to go through a deprecation and removal
17:17:46 <dustymabe> bgilbert: that WFM too
17:18:07 <dustymabe> we historically shipped their content because it was just all included in the linux-firmware package
17:18:16 <bgilbert> right
17:18:17 <jlebon> also WFM
17:18:21 <dustymabe> I think some of the problem now be that the GPU firmwares are getting larger
17:18:26 <bgilbert> might make sense as part of a larger space-savings initiative in the future
17:18:32 <dustymabe> +1
17:19:32 <jlebon> #proposed we will keep the firmwares for now as users currently rely on them. we may in the future remove them as part of a larger space-savings initiative.
17:20:07 <dustymabe> jlebon: +1 - thought the question may be: do we close the issue or leave it open?
17:20:11 <dustymabe> though*
17:20:46 <jlebon> dustymabe: i'd say close. we'd track a larger initiative in its own ticket.
17:21:17 <dustymabe> +1
17:21:48 <jlebon> will assume bgilbert is +1 based on the above, so:
17:21:49 <jlebon> #agreed we will keep the firmwares for now as users currently rely on them. we may in the future remove them as part of a larger space-savings initiative.
17:21:56 <bgilbert> +1 to proposed
17:22:02 <jlebon> :)
17:22:06 <jlebon> #topic Open Floor
17:22:12 <bgilbert> I was going to suggest mentioning it in https://github.com/coreos/fedora-coreos-tracker/issues/186 but that's also closed
17:22:43 <dustymabe> ok I have something
17:22:45 <jlebon> i think with layering, there's a bunch of things we could reconsider
17:22:59 <dustymabe> well a few things I guess
17:23:09 <dustymabe> we should get a talk or two submitted to devconf.cz
17:23:30 <dustymabe> I think they were asking for more os distro talks
17:24:00 <jlebon> oh interesting. hadn't noticed it was in the summer this time
17:24:03 <dustymabe> yep
17:24:11 <dustymabe> the other thing I wanted to bring up
17:24:32 <dustymabe> I just noticed after running my scripts today that one of the changes dropped off the list that definitely didn't get pushed to f39
17:24:36 <dustymabe> so I did some investigation
17:24:43 <dustymabe> and found a few missing changes
17:25:15 <dustymabe> that maybe we should discuss real quick
17:25:52 <jlebon> sure
17:26:00 <dustymabe> https://hackmd.io/T3F32w5aSiywOd_ekB8HKw?view
17:26:19 <dustymabe> so item 104 z13 as the Baseline for IBM Z Hardware
17:26:30 <dustymabe> item 105 Pcre Deprecation
17:26:44 <dustymabe> item 117  Server Prohibits Byte-swapped Clients
17:26:55 <dustymabe> item 118 Unified Kernel Support Phase 1
17:27:07 <dustymabe> those are the ones that were missing
17:27:37 <dustymabe> the Unified kernel one is something I hadn't looked at before
17:28:25 <jlebon> 117 is a definite skip
17:28:34 <dustymabe> jlebon: yep
17:28:43 <jlebon> the remaining ones, maybe we should discuss in the next meeting? i don't think it'll be real quick :)
17:29:33 <dustymabe> yeah. UKI phase 1 is mostly optional stuff
17:29:47 <dustymabe> not sure about the z13 baseline for IBM Z
17:29:51 <dustymabe> ok we can do that next meeting
17:30:10 <jlebon> not sure either. i wonder what the baseline z for RHEL is
17:31:19 <jlebon> i would assume it's transparent to us and just means that *there may be* things we could do better in e.g. cosa but we'd need an s390x SME
17:31:59 <jlebon> ok, will close the meeting in 45s unless there's anything else
17:32:44 <jlebon> #endmeeting