16:30:38 <spresti> #startmeeting fedora_coreos_meeting
16:30:38 <zodbot> Meeting started Wed Aug 23 16:30:38 2023 UTC.
16:30:38 <zodbot> This meeting is logged and archived in a public location.
16:30:38 <zodbot> The chair is spresti. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:30:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:38 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:31:02 <spresti> #topic roll call
16:31:32 <travier> .hello siosm
16:31:34 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:31:35 <dustymabe> .hi
16:31:37 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:46 <marmijo> .hello marmijo
16:31:47 <zodbot> marmijo: marmijo 'Michael Armijo' <marmijo@redhat.com>
16:31:52 <spresti> #chair siosm
16:31:52 <zodbot> Current chairs: siosm spresti
16:32:00 <spresti> #chair dustymabe
16:32:00 <zodbot> Current chairs: dustymabe siosm spresti
16:32:07 <ravanelli> .hi
16:32:08 <zodbot> ravanelli: ravanelli 'Renata Ravanelli' <renata.ravanelli@gmail.com>
16:32:12 <spresti> #chair marmijo
16:32:12 <zodbot> Current chairs: dustymabe marmijo siosm spresti
16:32:20 <spresti> #chair ravanelli
16:32:20 <zodbot> Current chairs: dustymabe marmijo ravanelli siosm spresti
16:32:31 <travier> You need to #chair travier, not siosm :)
16:32:38 <spresti> #chair travier
16:32:38 <zodbot> Current chairs: dustymabe marmijo ravanelli siosm spresti travier
16:32:43 <travier> 👍
16:32:43 <spresti> sorry about that lol
16:32:54 <travier> all good, that's confusing 😅
16:33:39 <davdunc> .hello2
16:33:40 <zodbot> davdunc: davdunc 'David Duncan' <davdunc@amazon.com>
16:33:49 <aaradhak> .hello aaradhak
16:33:50 <zodbot> aaradhak: aaradhak 'Aashish Radhakrishnan' <aaradhak@redhat.com>
16:33:56 <spresti> Ok we have a lot of items on our plate today. So I am going to start kicking us off
16:34:05 <spresti> #chair aaradhak
16:34:05 <zodbot> Current chairs: aaradhak dustymabe marmijo ravanelli siosm spresti travier
16:34:14 <spresti> #chair davdunc
16:34:14 <zodbot> Current chairs: aaradhak davdunc dustymabe marmijo ravanelli siosm spresti travier
16:34:25 <travier> Which one should we start with?
16:34:29 <spresti> #topic Action items from last meeting
16:34:33 <travier> which one is the most important?
16:34:40 <spresti> #info there were no action items from last meeting
16:34:50 <spresti> Uh I figured we could start with the f39 changes
16:35:12 <spresti> wdyt?
16:35:17 <travier> +1
16:35:17 <dustymabe> let's do those later
16:35:20 <travier> ah ok
16:35:25 <spresti> Ok
16:35:26 <dustymabe> i'm running a script now to update it
16:35:35 <spresti> #topic ConditionNeedsUpdate= (systemd unit) will never trigger
16:35:35 <travier> maybe moby then
16:35:43 <travier> that works too :)
16:35:45 <spresti> #link https://github.com/coreos/fedora-coreos-tracker/issues/1538
16:36:55 <travier> I can introduce that
16:37:06 <spresti> Thank you
16:37:22 <travier> The idea is that the ConditionNeedsUpdate= condition in systemd units will never trigger on rpm-ostree base systems
16:37:24 <travier> based*
16:38:06 <travier> We haven't seen issues from that yet, but it would require more investigation to figure out if this is a issue or simplify something we should document
16:38:19 <travier> spoiler: it's not easy to "fix"
16:39:02 <travier> if folks are interested in investigating, this would be a good ticket :)
16:39:09 <travier> Nothing more to do right now I'd say
16:39:22 <dustymabe> is there any way for us to make this work or it's just a fundamental thing with rpm-ostree that won't
16:40:19 <travier> I /think/ that there should be options to keep some timestamp but I'm not sure
16:40:46 <travier> If I remember correctly, our images used to ship some files with their timestamps from the repo (from overlays)
16:41:21 <dustymabe> I wonder if walters has hit this particular problem with ConditionNeedsUpdate= in the past
16:41:27 <dustymabe> it has to have come up, right?
16:41:58 <travier> Given that we do image based updates and run scripts there, usually we don't have the issues that those conditions work around
16:42:50 <travier> take the first one for example:
16:42:55 <travier> /usr/lib/systemd/system/ldconfig.service
16:43:33 <travier> /etc/ld.so.cache is part of the image, and if you don't modify it, then it's updated alonside image updates
16:43:56 <travier> So essentially this service is "unused" on rpm-ostree systems
16:44:27 <travier> This is more an issue for user created units that expect this to work from the documentation
16:45:38 <travier> Let's move on?
16:46:01 <spresti> Thank you for the input. Yeah lets switch over. It sounds like further investigation is needed.
16:46:31 <spresti> Are there any additional steps to get that ball moving?
16:46:52 <spresti> i.e reaching out to cwalters or updates team?
16:47:23 <travier> bringing that to them would be good
16:48:42 <travier> #action travier will bring that issue to the rpm-ostree / ostree team
16:48:46 <travier> let's move on
16:48:50 <spresti> Thank you
16:49:01 <spresti> #topic Ship moby-engine 23.0.x in Fedora CoreOS
16:49:13 <dustymabe> ok I added the meeting label to this one.
16:49:21 <spresti> #link https://github.com/coreos/fedora-coreos-tracker/issues/1476
16:49:36 <spresti> dustymabe: could you introduce it ?
16:49:53 <dustymabe> yep
16:50:30 <dustymabe> basically the maintainership of moby was in question about 4-5 months ago. a new group of maintainers took over and got a new build of moby out
16:50:37 <dustymabe> but it wasn't fully complete
16:51:06 <dustymabe> they did builds - the build for f38 sat in bodhi updates-testing
16:51:11 <dustymabe> and won't get promoted
16:51:25 <dustymabe> but the rawhide build (which is now part of f39) did make it through because there is no gating
16:51:56 <dustymabe> It appears it has most features but some subset is missing
16:52:10 <dustymabe> see https://bugzilla.redhat.com/show_bug.cgi?id=2093501#c71
16:52:25 <dustymabe> the open question is: what do we do about this?
16:52:51 <dustymabe> passively pick up the new moby-engine build let users report issues?
16:52:53 <spresti> Can we revert back / pin old version?
16:53:27 <dustymabe> spresti: we can but it's not great because obviously no one is building that version and it's not getting any updates of any kind
16:53:31 <travier> I don't think we should do anything specific here. We pick packages from Fedora as they come. We can help improve them, but we don't have to
16:53:50 <dustymabe> travier: normally for most any other package I would agree with you
16:54:08 <dustymabe> but I believe one of our two container runtimes might deserve some special consideration
16:54:18 <travier> If we pin to an older version then it open a lot of indirect problem, notably that we'll be the only ones using this combinaison of packages
16:54:32 <dustymabe> travier: agree. I don't desire to pin to the older version
16:55:06 <dustymabe> I think fifofonix already reported some success with the new package - so there is at least some success
16:55:52 <dustymabe> I think my proposal is to pick up the new package in the f39 update
16:56:05 <travier> reallisticaly, the only options I see are
16:56:05 <travier> A) drop moby
16:56:05 <travier> B) help with packaging
16:56:05 <travier> C) do nothing and ship as is
16:56:06 <dustymabe> but... should we warn users? should we say antyhing?
16:56:31 <travier> We know that A is not a great option
16:57:06 <travier> We can add a note to the update notes / coreos status post that we send for updates.
16:57:15 <travier> It will also be in next for a while for users to test
16:57:25 <dustymabe> yes.
16:57:45 <dustymabe> if they do find "blockers" what do we do about them?
16:59:18 <dustymabe> #proposed we will pick up the moby-engine update when our streams transition to Fedora 39. We will add a note to our f39 release communication about the update and any considerations that need to be made.
17:00:32 <travier> They submit to Fedora as blockers?
17:00:40 <spresti> If there are blockers we can attempt to fix them right (depending on severity and difficulty)?
17:01:02 <travier> we are an edition, we can suggest them as release blocker, fedora can decide if it blocks the release
17:01:33 <travier> We want to be more upstream in Fedora. Let's engage / use the mecanisms that we have there
17:01:43 <dustymabe> travier: ehh. we've generally held a slightly different process to fedora's on "release blocking" type stuff
17:02:14 <travier> I'm suggesting we move closer to what Fedora does right now
17:02:15 <dustymabe> but yes, participating more in that process is desirable
17:02:41 <dustymabe> if we really want something to block we'll need to get to work proposing new release criteria
17:02:45 <travier> They can't know something is breaking FCOS if we don't report it there
17:03:12 <dustymabe> thoughts on current #proposed ?
17:03:18 <spresti> dustymabe: +1
17:03:21 <travier> +
17:03:23 <ravanelli> +1
17:03:24 <travier> +
17:03:26 <travier> +1
17:03:30 <aaradhak> +1
17:03:49 <spresti> #agreed we will pick up the moby-engine update when our streams transition to Fedora 39. We will add a note to our f39 release communication about the update and any considerations that need to be made.
17:04:16 <spresti> #topic New Package Request: audit
17:04:29 <spresti> #link https://github.com/coreos/fedora-coreos-tracker/issues/1362
17:05:26 <spresti> Well it looks like this one has been going on for a while
17:05:42 <travier> I've added the meeting label to this one to propose shipping it in F39
17:06:25 <travier> We would have to remove the service binary / move it as a recommend and document how to use audit via auditctl commands instead of service ones
17:06:59 <travier> EOP
17:07:46 <dustymabe> hmm
17:08:43 <dustymabe> travier: there had been linked an upstream PR https://github.com/linux-audit/audit-userspace/commit/39802bffbfc62501461c916d9ccf748afdff7d94
17:08:50 <dustymabe> that's definitely in Fedora's RPMs now
17:09:44 <travier> yes
17:10:07 <dustymabe> travier: but the rpm still requires the old initscripts?
17:10:12 <dustymabe> package
17:10:14 <dustymabe> ?
17:10:17 <travier> excepted for the service dependency, it could be added now
17:10:23 <travier> the service one only
17:10:28 <travier> https://src.fedoraproject.org/rpms/audit/blob/rawhide/f/audit.spec#_20
17:11:48 <dustymabe> wow
17:12:01 <dustymabe> https://src.fedoraproject.org/rpms/audit/blob/rawhide/f/audit.spec#_152
17:12:28 <dustymabe> could the RPM just be modified now to call auditctl instead?
17:13:10 <travier> https://github.com/coreos/fedora-coreos-tracker/issues/1362#issuecomment-1690335372
17:13:15 <travier> the proposed steps
17:13:27 <travier> To make that happen, we need to replace the calls to `service` with the new auditctl commands in:
17:13:27 <travier> - https://src.fedoraproject.org/rpms/audit/blob/rawhide/f/audit.spec#_152
17:13:27 <travier> - https://src.fedoraproject.org/rpms/audit/blob/rawhide/f/audit.spec#_157
17:13:27 <travier> Then move `initscripts-service` to a `Recommends`:
17:13:27 <travier> - https://src.fedoraproject.org/rpms/audit/blob/rawhide/f/audit.spec#_19
17:13:27 <travier> Then document in Fedora / FCOS how to manage audit with the new `auditctl` command from:
17:13:30 <travier> - https://github.com/linux-audit/audit-userspace/commit/39802bffbfc62501461c916d9ccf748afdff7d94
17:13:46 <dustymabe> that sounds like a great plan!
17:14:35 <dustymabe> honestly the dep on `initscripts-service` is only named for preun and postun - so maybe we don't even need it as a recommend?
17:14:58 <travier> There is unfortunately a lot of docs that rely on that command out there
17:15:05 <dustymabe> yeah, that's fine
17:15:31 <travier> #proposed We'll fix the remaning issues in the audit package and we'll include it in Fedora CoreOS once ready
17:15:39 <dustymabe> +1
17:15:43 <spresti> +1
17:15:52 <travier> I had suggested F39 but we can do earlier
17:16:02 <travier> no preference
17:16:23 <dustymabe> it might be later :) - /me notes some periods of "freeze" coming up
17:16:33 <dustymabe> i'll be happy to have this one behind us
17:16:54 <spresti> We still need 2 more votes >.>
17:17:01 <marmijo> +1
17:17:09 <aaradhak> +1
17:17:40 <spresti> #agreed We'll fix the remaining issues in the audit package and we'll include it in Fedora CoreOS once ready
17:18:17 <spresti> #topic Handling of default users/groups
17:18:28 <travier> this is a long one, let's keep it for another meeting
17:18:43 <spresti> ok sounds good
17:18:59 <spresti> Lastly we just have the f39 changes are we up for them?
17:20:02 <dustymabe> let's punt - I have something else I need to bring up anyway
17:20:12 <spresti> I am taking silence as a yes
17:20:17 <spresti> #topic tracker: Fedora 39 changes considerations
17:20:28 <spresti> #link https://github.com/coreos/fedora-coreos-tracker/issues/1491
17:21:06 <spresti> subtopic 220 Clean Systemd-boot installs
17:21:13 <dustymabe> I was trying to update the copy in the description, but between talking here and my screen flicker I wasn't able to get around to it
17:21:26 <travier> dustymabe: do you want to bring up another topic?
17:22:05 <travier> I think we've looked at those already. The issue is not up to date
17:22:09 <dustymabe> spresti: i'm sorry - yes let's go to open floor (i'll update the copy for next time)
17:22:20 <spresti> dustymabe: no worries thank you :)
17:22:29 <spresti> #topic Open Floor
17:22:47 <dustymabe> I wanted to bring up the Fedora 39 test day for FCOS
17:23:21 <dustymabe> which we still need to make an issue for (see the checklist item from https://github.com/coreos/fedora-coreos-tracker/issues/1490)
17:23:28 <dustymabe> beta is coming out soonish
17:23:46 <dustymabe> https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
17:24:19 <dustymabe> I have two questions:
17:24:28 <dustymabe> 1. does anyone want to volunteer to organize the test day?
17:24:51 <dustymabe> 2. do we want to try to find a target week for the testing (we can discuss this next week too)
17:25:53 <spresti> I think we have fairly low attendance today so I would certainly ask next week as well.
17:26:23 <dustymabe> yep - can do
17:28:02 <spresti> Well since it seems fairly silent, I dont know if we have any volunteer's on our hands.
17:28:27 <spresti> Any other topics?
17:28:37 <dustymabe> That's all from me
17:29:08 <spresti> Well since we are near the end of time. I am going to go ahead and close us out
17:29:14 <spresti> #endmeeting