16:30:51 <jlebon> #startmeeting fedora_coreos_meeting
16:30:51 <zodbot> Meeting started Wed Jan  5 16:30:51 2022 UTC.
16:30:51 <zodbot> This meeting is logged and archived in a public location.
16:30:51 <zodbot> The chair is jlebon. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:30:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:51 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:31:03 <jlebon> #topic roll call
16:31:07 <davdunc> .hello2
16:31:08 <zodbot> davdunc: davdunc 'David Duncan' <davdunc@amazon.com>
16:31:31 <jmarrero> .hi
16:31:32 <zodbot> jmarrero: jmarrero 'Joseph Marrero' <jmarrero@redhat.com>
16:31:39 <dustymabe> .hi
16:31:40 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:51 <jlebon> #chair davdunc jmarrero dustymabe
16:31:51 <zodbot> Current chairs: davdunc dustymabe jlebon jmarrero
16:31:55 <lorbus> .hi
16:31:56 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:32:00 <jlebon> #chair lorbus
16:32:00 <zodbot> Current chairs: davdunc dustymabe jlebon jmarrero lorbus
16:32:13 <walters> .hi
16:32:13 <skunkerk> .hello sohank2602
16:32:13 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:32:16 <zodbot> skunkerk: sohank2602 'Sohan Kunkerkar' <skunkerk@redhat.com>
16:32:48 <jlebon> #chair skunkerk walters
16:32:48 <zodbot> Current chairs: davdunc dustymabe jlebon jmarrero lorbus skunkerk walters
16:33:28 <jlebon> ok, one more minute and we begin
16:34:09 <bgilbert> .hi
16:34:10 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:34:22 <jlebon> #chair bgilbert
16:34:22 <zodbot> Current chairs: bgilbert davdunc dustymabe jlebon jmarrero lorbus skunkerk walters
16:34:32 <jlebon> ok, let's go!
16:34:35 <jlebon> #topic Action items from last meeting
16:34:41 <jlebon> there are none!
16:34:49 <jlebon> moving on
16:34:50 <ravanelli> .hi
16:34:52 <aaradhak> .hello aaradhak
16:34:53 <zodbot> ravanelli: ravanelli 'Renata Renata Andrade Matos Ravanelii' <renata.ravanelli@gmail.com>
16:34:56 <zodbot> aaradhak: aaradhak 'Aashish Radhakrishnan' <aaradhak@redhat.com>
16:35:07 <jlebon> #topic New Package Request: microdnf
16:35:11 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/1050
16:35:18 <jlebon> walters or jmarrero: want to introduce this one?
16:35:26 <jlebon> #chair ravanelli aaradhak
16:35:26 <zodbot> Current chairs: aaradhak bgilbert davdunc dustymabe jlebon jmarrero lorbus ravanelli skunkerk walters
16:36:03 <walters> I think it's basically we find using `microdnf` convenient for some PoC work on the coreos layering effort
16:36:43 <jlebon> ack right. so to be clear, long-term ideally we wouldn't need microdnf at all
16:36:52 <walters> there's a lot of longer term questions around whether we continue this way (and would push us to align more with dnf) or later circle back and just do what we need in rpm-ostree, the same way we're doing everything else
16:38:07 <bgilbert> what compat constraints would we create by adding it?
16:38:16 <walters> (one huge thing I could speak for two hours straight about is how hard it is to write software that runs both as a systemd service offering a dbus API and needs to run in a container with no systemd running headless)
16:38:21 <jlebon> jmarrero: are the sizes in https://github.com/coreos/fedora-coreos-tracker/issues/1050#issue-1081544683 of the RPM files themselves?
16:38:49 <jlebon> bgilbert: part of the proposal is to shove it in some rpm-ostree-owned directory and not have it in PATH
16:38:54 <walters> and part of this is short-cutting vast chunks of infrastructure in rpm-ostree that are all about systemd/dbus because microdnf doesn't hard depend on those because its whole purpose in life is to run in a container
16:40:18 <travier> .hi siosm
16:40:19 <zodbot> travier: Sorry, but user 'travier' does not exist
16:40:25 <travier> .hello siosm
16:40:28 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:40:39 <jmarrero> You can see the proposed change with moving it to /usr/lib/rpm-ostree here: https://github.com/coreos/fedora-coreos-config/pull/1381
16:40:42 <jlebon> it'll still be in the rpmdb though. i guess we could enhance rpm-ostree to learn to extract files from rpms though not sure it's worth it
16:40:50 <jlebon> #chair travier
16:40:50 <zodbot> Current chairs: aaradhak bgilbert davdunc dustymabe jlebon jmarrero lorbus ravanelli skunkerk travier walters
16:41:48 <jmarrero> jlebon: yes the sizes of the rpms.
16:41:48 <walters> I think it's worth emphasizing there's no long term commitment from this, it would just help us short term use official fcos builds for layering PoC work
16:41:57 <dustymabe> I've had a desire in the past to have microdnf in FCOS (well, at the time it was Atomic Host), but this feels a little off to me. We often reject new packages for more legitimate reasons than "we want to experiment with a brand new use case that most people probably aren't interested in"
16:42:04 <miabbott> .hello miabbott
16:42:05 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:42:11 <jlebon> jmarrero: ahh, should be size on disk instead to be more accurate (`rpm -qi` will give you that)
16:42:48 <jlebon> #chair miabbott
16:42:48 <zodbot> Current chairs: aaradhak bgilbert davdunc dustymabe jlebon jmarrero lorbus miabbott ravanelli skunkerk travier walters
16:42:49 <dustymabe> well. they may be interested in it in the future
16:43:06 <dustymabe> i guess you could say the same thing about clevis/tang
16:43:32 <walters> in this case, no one aside from rpm-ostree when run in a container can use this
16:44:24 <dustymabe> because we neuter it?
16:44:28 <jmarrero> jlebon: ahh, sorry about that. I will update it then.
16:44:45 <jlebon> dustymabe: essentially it's not user-facing at all
16:45:11 <walters> it's not in `/usr/bin`
16:45:13 <jlebon> as mentioned above, we move the binary out of PATH, and it's wrapped by rpm-ostree
16:45:24 <mnguyen_> .hello mnguyen
16:45:25 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:45:29 <jlebon> #chair mnguyen_
16:45:29 <zodbot> Current chairs: aaradhak bgilbert davdunc dustymabe jlebon jmarrero lorbus miabbott mnguyen_ ravanelli skunkerk travier walters
16:45:30 <travier> I'm OK if it is out of PATH as it's not something that will be used directly by users.
16:45:58 <walters> hmm, maybe we can only add this on next-devel or something for now?
16:46:06 <travier> But still wondering if directly vendoring it in rpm-ostree would make sense?
16:46:26 <dustymabe> walters: would that help us experiment while also not exposing the change directly to users?
16:46:27 <walters> I wouldn't want to say only rawhide because well, the whole way Fedora works sadly means rawhide is constantly broken
16:46:39 <jlebon> travier: good point. we do submodule libdnf already...
16:47:09 <dustymabe> i'm actually a fan of unvendoring libdnf (though that opinion isn't held to strongly because I don't understand all of the "why")
16:47:24 <walters> yeah, but there's all this CLI logic that lives in microdnf - things like progress bar reporting
16:47:31 <travier> That way it gets updated / removed as needed as the code in rpm-ostree changes
16:47:54 <walters> dustymabe: covered here https://coreos.github.io/rpm-ostree/HACKING/#testing-with-a-custom-libdnf
16:48:02 <jlebon> walters: we could vendor the app itself
16:48:15 <walters> true...
16:48:32 <jlebon> dustymabe: we do want that eventually
16:48:39 <dustymabe> jlebon: +1
16:49:16 <jlebon> and maybe then (if we go the submodule route) we could drop some of those extra deps
16:49:53 <jlebon> (and we avoid shipping libdnf twice)
16:49:53 <dustymabe> another thing to think about is maintenance over time. what's less maintenance burden for us?
16:51:32 <jlebon> dustymabe: this isn't a steady state, it's just for POC'ing coreos layering
16:51:38 <walters> dustymabe: I think *short* term, less maintenance burden is this proposal.  But it does seem to me longer term less burden for the broader "us" including other Fedora editions, dnf team etc. is rpm-ostree using the shared libdnf and sharing more code where applicable with dnf/microdnf
16:51:54 <dustymabe> walters: agree
16:53:53 <lucab> .hi
16:53:54 <zodbot> lucab: lucab 'Luca BRUNO' <lucab@redhat.com>
16:54:31 <jlebon> walters, jmarrero: is it worth investigating the submodule route?
16:54:34 <jlebon> #chair lucab
16:54:34 <zodbot> Current chairs: aaradhak bgilbert davdunc dustymabe jlebon jmarrero lorbus lucab miabbott mnguyen_ ravanelli skunkerk travier walters
16:55:12 <dustymabe> ok some thoughts:
16:55:18 <dustymabe> - This feels a little like we're trying to fit a square peg in a round hole with FCOS (trying to make it run in a container).
16:55:20 <dustymabe> - if we proceed with this I'm +1 for doing in `next-devel`/`next` for POC
16:55:22 <dustymabe> - we should re-evaluate in the future after the POC is done what we want to do
16:55:24 <dustymabe> - steps towards unvendoring libdnf in rpm-ostree would be a positive
16:55:26 <dustymabe> - making microdnf only available to the system seems awkward (it would fail to run anyway because of readonly FS) should we just leave it be?
16:55:50 <dustymabe> should have numbered those so we could reference them
16:56:08 <dustymabe> A. This feels a little like we're trying to fit a square peg in a round hole with FCOS (trying to make it run in a container).
16:56:10 <dustymabe> B. if we proceed with this I'm +1 for doing in `next-devel`/`next` for POC
16:56:12 <dustymabe> C. we should re-evaluate in the future after the POC is done what we want to do
16:56:14 <dustymabe> D. steps towards unvendoring libdnf in rpm-ostree would be a positive
16:56:16 <dustymabe> E. making microdnf only available to the system seems awkward (it would fail to run anyway because of readonly FS) should we just leave it be?
16:56:18 <dustymabe> there
16:56:43 <walters> jlebon: Mmmm....the build system stuff for that would be hairy I think
16:56:57 <davdunc[m> for C. are we proposing an indeterminate time for evaluation?
16:56:59 <jlebon> dustymabe: re. E it wouldn't fail in a container
16:57:29 <dustymabe> but isn't that what we want? for it to run fine in a container?
16:57:31 <jlebon> so it'd expose the full microdnf CLI API to coreos layering users
16:57:32 <walters> dustymabe: We're only supporting "running FCOS as a container" sufficient to perform a *build* operation
16:57:39 <jmarrero> jlebon: If you mean doing the submodule route for the PoC work and then using the shared libdnf, It feels like it's more trouble than is worth for a temporary path. When long term we are aiming to use libdnf ourselves.
16:59:23 <dustymabe> jlebon: and that would cause rpm-ostree to lose track of things?
17:00:08 <walters> davdunc: Time frame here indeed fuzzy/ill-defined
17:00:29 <jlebon> dustymabe: i'm more concerned with implicitly committing to its CLI. whereas if rpm-ostree wraps it, we can only support the bits from it we want
17:00:32 <davdunc> walters: makes sense. I was only asking as it is good to shoot for a date.
17:00:51 <jlebon> dustymabe: and leaves the door open for rpm-ostree doing it itself in the future leveraging libdnf rather than microdnf
17:00:59 <davdunc> I am also okay with missing dates and setting new ones :)
17:02:01 <walters> well, since the enhancement and https://fedoraproject.org/wiki/Changes/OstreeNativeContainer we're accepted we're basically saying we're going to do *something* of this form
17:02:47 <jlebon> instead of time frame, we can just constrain it to next and then we can discuss down the line if we want this in testing/stable too if we haven't cleaned up that part of coreos layering
17:03:47 <jlebon> but we can say we'll aim to drop the dep before then
17:04:02 <walters> I think next-only works?
17:04:18 <dustymabe> like I said, it feels a bit hairy, but I think I'm digesting it a bit more because of the desired use that it's somewhat necessary (unless we somehow inject more things into the container later). I'm interested in thougths from others. travier bgilbert lucab?
17:04:51 <davdunc> so then the time schedule for POC is through 36 release or ...
17:05:20 <dustymabe> davdunc: seems reasonable
17:05:30 <davdunc> yea. I like it.
17:05:39 <travier> Would it be possible to add it only to the container image and not everywhere else?
17:05:39 <lucab> would it be feasible to produce an extension container with /usr/bin/microdnf in sync with FCOS releases, and then do a multi-stage / copy-from dance to bring it into the build base?
17:05:54 <travier> :)
17:05:56 <dustymabe> ha
17:06:44 <travier> My main concern is that we are shipping client side a tool we want to use only server/build side
17:06:51 <walters> travier: that is indeed possible.  But it complicates things in a different way because now we have this new thing that is not a result of `cosa build
17:07:06 <lucab> (for the record, I'm ok with having it in the base FCOS image outside of PATH, I was just thinking about other container-specific options)
17:07:41 <walters> travier: Yes, 100% true.  I think longer term we want a separate "builder" image indeed
17:08:01 <dustymabe> indeed
17:08:01 <walters> this is part of https://github.com/coreos/fedora-coreos-tracker/issues/1054
17:08:33 <dustymabe> for example, as part of this POC we could decide we prefer the "builder" image approach where microdnf is injected
17:08:51 <dustymabe> but. I think for this POC we could proceed as proposed
17:10:10 <bgilbert> dustymabe: I'm actually not that concerned about this one, if we keep it out of the API and aren't creating compat constraints for our own tooling.  especially since it's small and temporary.  it's good to avoid adding _too_ much friction for experimentation within the WG.
17:10:23 <dustymabe> +1
17:10:54 <dustymabe> I think we should make it clear in the title and description of the issue that it's intent is to be hidden from end users
17:11:07 <jlebon> #proposed We will add microdnf to FCOS on the next stream only. It will reside outside of PATH and only be used by rpm-ostree for POC purposes. We will re-evaluate at f36 release time whether to remove it, keep it in next, or possibly propagate it to testing and stable.
17:11:22 <dustymabe> ack
17:11:22 <walters> +1
17:11:24 <bgilbert> +1
17:11:49 <lorbus> +1
17:11:51 <jmarrero> +1
17:11:57 <jlebon> #agreed We will add microdnf to FCOS on the next stream only. It will reside outside of PATH and only be used by rpm-ostree for POC purposes. We will re-evaluate at f36 release time whether to remove it, keep it in next, or possibly propagate it to testing and stable.
17:12:12 <jlebon> ok let's move on. i think we have time for another ticket at least
17:12:15 <dustymabe> should we leave the issue open until we decide if it goes into `testing/stable` ?
17:12:24 <dustymabe> we can decide that later
17:12:26 <dustymabe> +1
17:12:31 <jlebon> #topic New Package Request: nano (and explicit choice for default editor)
17:12:34 <jlebon> #link https://github.com/coreos/fedora-coreos-tracker/issues/1058
17:12:46 <jlebon> travier: want to discuss this?
17:13:29 <travier> sure
17:14:14 <travier> Essentially this is about explicitly choosing a default editor
17:14:30 <travier> In this case, it is nano like what Fedora upstream did
17:14:49 <travier> It's a really small addition and would not remove vi
17:15:17 <travier> Should be easy to revert for those that don't like it (needs to be confirmed/tested)
17:15:45 <lorbus> I'm in favor of this. Keeping the defaults that Fedora has chosen intact to me seems the right thing to do
17:15:45 <travier> This came up as part of the os extensions testing I've recently added
17:16:07 <dustymabe> +1 - while I much prefer VI and it will cause some issues for users like me when tools use $EDITOR it's easily worked around and also gets us in line with Fedora's defaults
17:16:34 <dustymabe> basically this is always going to come down to $opinion so going with "what Fedora chooses" can really only be the right answer
17:16:51 <travier> Personally I use vi_m_ and I overlay it so I don't even use any of the defaults we provide
17:17:22 <bgilbert> +1 to following Fedora
17:17:34 <travier> Providing both also means that we don't really make a strong choice
17:18:07 <jmarrero> +1 Fedora default
17:18:13 <walters> Added my +1 to ticket too
17:18:39 <travier> #link https://github.com/coreos/fedora-coreos-config/pull/1395
17:18:45 <travier> For the os extension test
17:19:06 <travier> #link https://github.com/coreos/fedora-coreos-config/pull/1394
17:19:21 <travier> for the, to be tested, revert to vim as default
17:19:21 <jlebon> travier: for background, was it a user who requested this?
17:19:50 <davdunc> -1 to vim as default.
17:20:15 <travier> jlebon: no, I re-discovered it while thinking about the common packages I overlay, why we don't include them and the fedora defaults change I remembered recently
17:20:27 <jlebon> travier: ack ok
17:21:10 <travier> davdunc: The link includes the "to be tested" command that enables you to revert to the previous default after we make this change
17:21:19 <davdunc> I see.
17:21:25 <jlebon> ok so i'm fine with this, but it does feel a bit funny to add more stuff when no one is really asking for it
17:21:30 <davdunc> thanks travier
17:21:58 <jlebon> anyway, looks like there's general agreement. let me write a proposal
17:22:02 <dustymabe> jlebon: the way I think about it is.. if this were an approved change request for f36, what would we do?
17:22:12 <dustymabe> I think we'd add it
17:22:28 <dustymabe> unless there were good reasons not to
17:22:41 <jlebon> #proposed We will add nano to FCOS and make it the default editor on new installs.
17:23:06 <walters> Wait why just new installs?
17:23:07 <travier> jlebon: the change is for all installs
17:23:24 <jlebon> ahhh ok. misunderstood
17:23:27 <travier> It's harder to make that only for new installs
17:23:32 <jlebon> #proposed We will add nano to FCOS and make it the default editor.
17:23:49 <jlebon> dustymabe: minimalism
17:23:55 <lucab> does this get entangled with alternatives somehow, or do nano & vim stay clearly separate?
17:24:02 <dustymabe> :)
17:24:03 <lucab> *vi
17:24:07 <dustymabe> lucab: I think they stay separate
17:24:24 <dustymabe> i think all the "defaults" rpm does is deliver a bash profile dropin that sets the EDITOR to nano
17:24:36 <davdunc> +1 to nano as default.
17:24:37 <travier> From my understand so far, it's only dropping a few shell config files to export the EDITOR
17:24:42 <travier> no alternatives AFAIK
17:24:48 <lucab> good
17:24:58 <travier> And of course we are not removing vi here
17:25:16 <davdunc> yea. it's not a significant in my opinion and those who can't manage their own editor should have a simplified choice.
17:25:27 <lucab> (we may dare though :)
17:25:36 <davdunc> lucab: LOL.
17:26:03 <travier> Removing vi is harder as users may rely on it being there now that it has been in FCOS for a while
17:26:13 <travier> And I don't think it's worth the effort
17:26:25 <dustymabe> and you might have to fight me!!
17:26:27 <jmarrero> we could alias vi to nano ;)
17:26:29 <dustymabe> :)
17:26:36 <travier> (I'm +1 for the change obviously as I proposed it)
17:26:47 <travier> :D
17:27:06 <miabbott> +1 to proposal
17:27:15 <bgilbert> +1
17:27:19 <jmarrero> +1
17:27:20 * dustymabe wonders if this needs any sort of announcement
17:27:25 <jlebon> #agreed We will add nano to FCOS and make it the default editor on new installs.
17:27:41 <davdunc> yea. my personal editor is that which shall not be named in a room full of vi users, so neither really changes my workflow as a default.
17:28:07 <lorbus> I don't care about vim but can we remove docker from FCOS now?
17:28:09 * lorbus ducks
17:28:12 <davdunc> and I think that the added effort of installing vi wouldn't slow any of you down either.
17:28:16 <travier> I don't think this really needs an announcement but we can mention it when folks complain about us not following Fedora default :D
17:28:28 <dustymabe> :)
17:28:33 <travier> lorbus: not happening sorry :D
17:28:50 <jlebon> heh
17:28:55 <jlebon> ok cool, let's do a quick open floor
17:28:59 <dustymabe> would be nice to have a docs entry on how to get back to VI being default (butane snippet)
17:29:05 <jlebon> #topic Open Floor
17:29:09 <travier> dustymabe: will write that
17:29:13 <dustymabe> thanks travier
17:29:28 <dustymabe> happy new year everyone
17:29:36 <lorbus> might be interesting for some. I put together a small repo to manage and merge butane configs: https://github.com/LorbusChris/butane-config-template
17:29:51 <lorbus> it's pretty trivial, but some might still find it useful
17:30:02 <buckaroogeek> lorbus: thanks
17:30:06 <dustymabe> anybody want to chase down issues in authselect? https://github.com/coreos/fedora-coreos-tracker/issues/1051
17:30:23 <bgilbert> #info the latest release of coreos-installer has a bunch of new sugar for customizing the live images
17:30:29 <bgilbert> #link https://coreos.github.io/coreos-installer/cmd/iso/#coreos-installer-iso-customize
17:30:36 <bgilbert> #link https://coreos.github.io/coreos-installer/cmd/pxe/#coreos-installer-pxe-customize
17:30:50 <jlebon> dustymabe: i think walters is looking at it
17:31:13 <dustymabe> that would be awesome!
17:31:13 <jlebon> bgilbert: awesome work on that!
17:31:14 <walters> Yeah
17:31:29 <dustymabe> there are two authselect issues
17:31:31 <walters> Had to open the hood on the authselect code
17:31:34 <bgilbert> jlebon: thanks! :-)
17:31:38 <dustymabe> one was lua and the other was the nsswitch stuff
17:31:50 <dustymabe> i assume you're doing both?
17:32:15 <dustymabe> open that hood: 🚘
17:32:19 <walters> Trying but I may call uncle if it takes me more than today
17:32:38 * jlebon has to go afk. will let dustymabe close up. thanks all!
17:32:44 <walters> https://github.com/authselect/authselect/pull/288 came out of just reading
17:32:45 <dustymabe> walters: in that case I'll pass it to the next volunteer
17:33:02 <bgilbert> dustymabe: I'll close
17:33:18 <dustymabe> +1
17:34:04 <bgilbert> cool.  if no one has anything else, will close the meeting in 60s
17:34:46 <bgilbert> (oops, dustymabe, I misread your comment to walters)
17:35:15 <bgilbert> #endmeeting