16:31:17 <jlebon> #startmeeting fedora_coreos_meeting
16:31:17 <zodbot> Meeting started Wed Dec  1 16:31:17 2021 UTC.
16:31:17 <zodbot> This meeting is logged and archived in a public location.
16:31:17 <zodbot> The chair is jlebon. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:31:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:31:17 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:31:26 <dustyweb> .hellomynameis dustymabe
16:31:27 <zodbot> dustyweb: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:44 <copperi[m]> .hello copperi
16:31:45 <zodbot> copperi[m]: copperi 'Jan Kuparinen' <copper_fin@hotmail.com>
16:31:48 <jlebon> #topic roll call
16:31:54 <jlebon> #chair dustyweb copperi[m]
16:31:55 <zodbot> Current chairs: copperi[m] dustyweb jlebon
16:33:03 <dustyweb> hey all - here under a different alias today - rebuilding my home desktop as we speack
16:33:08 <dustyweb> speak*
16:33:36 <jlebon> dustyweb: hmm, that's exactly what the real dustymabe would say
16:33:47 <miabbott> .hello miabbott
16:33:50 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:33:50 <travier[m]> .hello siosm
16:33:53 <zodbot> travier[m]: siosm 'Timothée Ravier' <travier@redhat.com>
16:34:03 <jlebon> #chair miabbott travier[m] mnguyen
16:34:03 <zodbot> Current chairs: copperi[m] dustyweb jlebon miabbott mnguyen travier[m]
16:34:09 <walters> jlebon: haha
16:34:12 <lucab> .hi
16:34:13 <zodbot> lucab: lucab 'Luca BRUNO' <lucab@redhat.com>
16:34:19 <walters> .hello2
16:34:20 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:34:26 <nemric> hi
16:34:28 <jlebon> #chair walters lucab nemric
16:34:28 <zodbot> Current chairs: copperi[m] dustyweb jlebon lucab miabbott mnguyen nemric travier[m] walters
16:35:13 <jlebon> alright nice, started with low hopes, but we got a crowd now \o/
16:35:44 <jlebon> ok cool, let's get started then!
16:35:50 <jlebon> #chair saqali_
16:35:50 <zodbot> Current chairs: copperi[m] dustyweb jlebon lucab miabbott mnguyen nemric saqali_ travier[m] walters
16:36:06 <jlebon> #topic Action items from last meeting
16:36:16 <jlebon> -ENOENT
16:36:22 <jlebon> nice job, let's move on then
16:36:43 <jlebon> #topic New Package Request: cachefilesd
16:36:48 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/1029
16:37:04 <nemric> that's my issue ! yeah !
16:37:18 <dustyweb> nemric - nice
16:37:38 <jlebon> nemric: cool. wanted to make sure you got a satisfactory answer online
16:38:22 <nemric> yes that sound right, didn't try yet as the server is running for now
16:38:54 <lucab> for this one, I think the usual "run it in a container" option is not sanely feasible
16:39:06 <nemric> does that mean it won't be included despite the only 75 kb size ?
16:39:19 <jlebon> nemric: size is only one factor
16:39:29 <nemric> ok
16:40:00 <jlebon> overall I agree with travier[m] that it's a good candidate for layering
16:40:07 <nemric> It can't be containerized, too much low level dependencies
16:40:30 <jlebon> what sucks right now is our layering UX
16:40:40 <dustyweb> yeah, not a good candidate for container - but layering should work fine I would think
16:40:50 <nemric> yes, i was waiting for upvotes but thez didn't come :(
16:41:01 <ravanelli> .hi
16:41:02 <zodbot> ravanelli: ravanelli 'Renata Renata Andrade Matos Ravanelii' <renata.ravanelli@gmail.com>
16:41:09 <jlebon> #chair ravanelli
16:41:09 <zodbot> Current chairs: copperi[m] dustyweb jlebon lucab miabbott mnguyen nemric ravanelli saqali_ travier[m] walters
16:41:13 <dustyweb> the only hiccup there is the boot sequence would have to be ordered correctly
16:41:46 <nemric> yes, that would make the setting a bit "hard"
16:41:52 <travier[m]> We could add it to the image as it's small but not not a super requested feature as well and we don't really know how well it works / it is supported (and if it is useful outside of NFS)
16:42:26 <travier[m]> And this would require testing for inclusion
16:42:48 <nemric> I use it since a few weeks, it doesn't look very reliable :/
16:42:49 <dustyweb> travier[m] - because we said we wanted to add tests any time we add a package ?
16:43:32 <nemric> it can be user with an other "nfs like" remote fs
16:43:42 <travier[m]> I don't think we always need to block on testing before adding packages but it would be great if from now on we would "gate" on at least basic functionality testing
16:43:56 <dustyweb> travier[m] - yeah I agree - that would be nice
16:43:58 <lucab> (I'll be honest, even in NFS setups I haven't encountered this service before)
16:44:11 <travier[m]> (I had never heard of it either)
16:44:28 <dustyweb> nemric - are you saying that cachefiled hasn't been very reliable for you in your local testing with it over the past few weeks?
16:45:23 <walters> it's under a big rewrite https://listman.redhat.com/archives/linux-cachefs/2021-November/msg00058.html
16:46:30 <nemric> yes ! I didn't run a lot of test but it looks like it really depend on nfs server settings it happen that it won't survive to reboots
16:47:15 <dustyweb> yeah - I think that's even more evidence that we should recommend to "layer" for now and we'll re-evaluate in the future if we get a lot of feature requests when the rewrite lands
16:47:51 <lucab> I'm personally on the side of "candidate for layering", though yes the provisioning flow becomes more complex
16:47:53 <jlebon> nemric: can you try out the layering suggestion and report back how well/not well that works for you?
16:48:30 <nemric> yes, I will continue to "test" it during some times and read for @walters link
16:48:52 <jlebon> nemric: +1  thanks
16:48:59 <nemric> yes, i can do that :)
16:49:28 <travier[m]> thanks
16:49:40 <lucab> just as a note, it doesn't support config fragments but just a single monolithic .conf file (though it doesn't really have many knobs right to tweak now)
16:49:52 <nemric> probably not for next wednesday but nobody is really waiting for this feature :D
16:50:31 <dustyweb> nemric - if you have trouble getting a ignition/butane config that works - hit us up and we'll help
16:50:49 <jlebon> re. ordering complexity, I'd really like to fix the layering UX soon which will resolve that. I think personally it's complementary to the coreos layering efforts
16:51:05 <dustyweb> jlebon++
16:51:16 <travier[m]> jlebon: +1
16:51:18 <nemric> thanks ;)
16:51:22 <lucab> should we maybe try to reach to the author to see whether it's still recommended for use?
16:52:20 <nemric> It would not be so hard to ordering with systemd dependencies, just waiting for cahefilesd before mounting units
16:52:58 <nemric> and I only use it on a "automount" unit for a dev envoronment
16:53:00 <dustyweb> lucab - i.e. the old version versus the rewritten version?
16:53:04 <miabbott> wow, last version of it was from 2011
16:53:17 <nemric> wow !
16:53:17 <lucab> (it didn't move in years, and I couldn't find a git/svn repo for it?)
16:53:20 <dustyweb> miabbott - does that mean it's stable?
16:53:28 <dustyweb> :)
16:53:54 <nemric> it's doesn't look stable at my eyes
16:54:08 <lucab> dustyweb: I think the "rewritten version" is really "make this work right directly in the kernel", but I don't really know much in that area
16:54:15 <dustyweb> +1
16:54:33 <jlebon> ok cool, ready to move on?
16:54:43 <nemric> ok
16:54:49 <miabbott> it predates RHEL7 which makes me wonder how well it fits with an F35 based OS
16:55:11 <miabbott> but lets move on
16:55:24 <nemric> it uses fscahe which is a kernel functionnality
16:55:27 <jlebon> oh actually
16:55:44 <jlebon> I was going to switch to https://github.com/coreos/fedora-coreos-tracker/issues/799, but jaime isn't here, and it might just be we forgot to untag it
16:56:26 <jlebon> so in that case... there are no other topics for today
16:56:49 <jlebon> are there any other tickets anyone wants to bring up?
16:58:56 <nemric> yes, about user systemd units, but before, I'd like to promote my butane schema that could pre validate bu file for https://github.com/coreos/fedora-coreos-tracker/issues/799
16:59:33 <dustyweb> should we do a #proposed for the current topic?
16:59:41 <jlebon> nemric: cool, thanks
16:59:47 <jlebon> sure
17:01:01 <jlebon> #proposed we will not add cachefilesd to the host for now. we will wait for feedback from the reporter as well as from the current upstream rewrite before re-evaluating. meanwhile, package layering should work.
17:01:16 <walters> +1
17:01:18 <dustyweb> +1
17:01:23 <nemric> +1
17:01:36 <jlebon> #agreed we will not add cachefilesd to the host for now. we will wait for feedback from the reporter as well as from the current upstream rewrite before re-evaluating. meanwhile, package layering should work.
17:01:57 <nemric> agree
17:02:26 <jlebon> if there's nothing else... this is more process-oriented, though this came up recently in conversation:
17:02:29 <travier[m]> 1
17:02:33 <travier[m]> +1
17:02:34 <jlebon> #topic Have a mechanism for syncing release checklists across projects
17:02:39 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/1035
17:03:08 <jlebon> we have lots of checklists, which is neat. but managing them is hard.
17:03:33 <jlebon> e.g. there are near duplicate release checklists for many of the Rust projects we have
17:04:27 <jlebon> does anyone have any ideas how we could simplify things there?
17:05:26 <jlebon> my low-tech solution is to keep them in e.g. fedora-coreos-tracker and have a github action which just keeps them in sync
17:05:50 <dustyweb> I'm not intimately familiar with the release process for each project... but we could maybe write a tool that automates the common bits
17:05:59 <travier[m]> I think we can have an org wide .github dir but that might not help here :/
17:06:03 <dustyweb> not sure if that's even possible
17:06:24 <lucab> a 'coreos-procedures' repo used as a submodule in the other consumers, and dependabot to forward the updates
17:06:41 <travier[m]> Or we could move the checklists out of individual projects and into another repo just for release tracking
17:07:06 <jlebon> lucab: nice, that's clever
17:07:26 <lucab> I think issue templates still need to live under .github/, but I'd need to check
17:07:30 <travier[m]> Hum, would a submodule work for .github?
17:07:43 <jlebon> dustyweb: agreed re. automation. that should be our ultimate goal IMO
17:08:08 <jlebon> it doesn't have to be under .github though, no?
17:08:21 <jlebon> we won't get the nice UX, but we can still provide a link in the README or something to create from the template
17:09:46 <lucab> I don't know what are the GH limitations around all of this. It may work in theory, but there are quite a few caveats to check.
17:10:05 <jlebon> yeah, agreed
17:10:31 <lucab> On the positive side, it could allow a single repo-wide find-and-replace
17:11:02 <jlebon> lucab: yeah, that's what I'm after. even if there's a lot of duplication, having it all in the same place would help a lot
17:11:24 <lucab> yeah gotcha
17:11:52 <travier[m]> If we don't use the nice template, let's not add a submodule to all repos just for that. We can use another repo just for release templates
17:11:54 <dustyweb> if we make it legit documentation we could literally share common parts and have it all rendered nicely using github pages or something
17:12:14 <travier[m]> I don't mind submodules but it adds management overhead
17:12:21 <dustyweb> i.e. no copy/paste at all - just a single source of truth replicated
17:12:28 <travier[m]> and this would not be used in 99% of cases by anyone
17:13:16 <lucab> yes, not a fan of git submodules either, I only threw them in the mix because then we can offload the updating burden to dependabot
17:13:39 <travier[m]> I also does not force us to use the exact same release process for all repos but makes it really easy to update all of them at once
17:13:54 <jlebon> related to dustyweb's point... it's tempting to write a bot to start cutting releases. for the rust projects, i'm sure there are some things that already exist for rust -> crates.io and we could (re)look at packit for the fedora side
17:14:25 <lucab> anyway, I'll note this option in the ticket and then I'll sleep on it a bit more
17:14:35 <dustyweb> note - it doesn't have to be a bot
17:14:41 <dustyweb> could be a script
17:15:03 <dustyweb> or whatever, the point is that the logic is encoded in the script (and thus less steps for each individual project)
17:15:05 <jlebon> dustyweb: that'd be a good starting point
17:16:04 <jlebon> ok cool. let's move on to...
17:16:08 <jlebon> #topic Open Floor
17:16:22 <jlebon> anything else anyone wants to bring up?
17:16:32 <nemric> ^^
17:16:46 <lucab> the fine border between a bot and a script is: who hold the tokens/secrets
17:16:52 <nemric> https://github.com/coreos/butane/issues/194
17:18:07 <lucab> ah yes, that's a good one
17:18:24 <nemric> thanks @lucab
17:18:45 <dustyweb> i'm guessing the transition to f35 has gone smoothly?
17:19:06 <dustyweb> anyone seen any issues?
17:19:19 <nemric> not any on my side
17:19:22 <lucab> speaking of which, I'm not sure why we are keeping in the context of butane sugar, I have a feeling it (or at least some parts) could go into Ignition proper
17:19:42 <jlebon> lucab: +1  my thoughts as well
17:20:06 <travier[m]> +1
17:20:09 <jlebon> Ignition already knows about users, and already knows about systemd services. seems natural
17:20:46 <dustyweb> totall agree
17:21:26 <nemric> I'm not sure to understand everything now :/
17:21:30 <lucab> that way we'd even avoid hardcoded paths coming from the transpiler, leaving some more wiggle room to Ignition internally
17:22:07 <lucab> nemric: no worries, just collectively pondering where to implement that feature
17:22:43 <nemric> ok, but some services could bewritten in /etc/systemd/user and would nedd to be enabled with --global argument
17:22:45 <lucab> (the final result shouldn't change, it would still be exposed through Butane)
17:23:40 <nemric> ;) @dustyweb
17:23:46 <lucab> nemric: yes, Ignition could take care of that once it knows about a unit name/content/scope
17:24:12 <nemric> yes that's the goal
17:24:21 <lucab> I'll put this into the ticket
17:25:21 <jlebon> lucab: +1 thanks
17:25:24 <jlebon> anything else?
17:25:49 <dustyweb> not from I
17:25:56 <nemric> no more from I
17:26:15 <jlebon> counting down from 45s
17:26:45 <nemric> thanks everybody
17:27:00 <jlebon> #endmeeting