2025-02-11 15:00:34 <@jbrooks:matrix.org> !startmeeting fedora_bootc_meeting 2025-02-11 15:00:36 <@meetbot:fedora.im> Meeting started at 2025-02-11 15:00:34 UTC 2025-02-11 15:00:36 <@meetbot:fedora.im> The Meeting name is 'fedora_bootc_meeting' 2025-02-11 15:00:46 <@dustymabe:matrix.org> !hi 2025-02-11 15:00:46 <@jbrooks:matrix.org> !topic roll call 2025-02-11 15:00:47 <@zodbot:fedora.im> Dusty Mabe (dustymabe) - he / him / his 2025-02-11 15:00:57 <@rsturla:fedora.im> !hi 2025-02-11 15:00:59 <@zodbot:fedora.im> None (rsturla) 2025-02-11 15:01:05 <@walters:fedora.im> !hi 2025-02-11 15:01:06 <@zodbot:fedora.im> Colin Walters (walters) 2025-02-11 15:01:08 <@jbrooks:matrix.org> !hi jasonbrooks 2025-02-11 15:01:10 <@zodbot:fedora.im> Jason Brooks (jasonbrooks) - he / him / his 2025-02-11 15:01:29 <@hricky:fedora.im> !hi 2025-02-11 15:01:30 <@zodbot:fedora.im> Hristo Marinov (hricky) - he / him / his 2025-02-11 15:01:33 <@jmarrero:matrix.org> !hi 2025-02-11 15:01:34 <@jlebon:fedora.im> !hi 2025-02-11 15:01:36 <@zodbot:fedora.im> None (jlebon) 2025-02-11 15:01:37 <@zodbot:fedora.im> Joseph Marrero (jmarrero) 2025-02-11 15:01:53 <@bbaude:matrix.org> !hi 2025-02-11 15:01:55 <@zodbot:fedora.im> No Fedora Accounts users have the @bbaude:matrix.org Matrix Account defined 2025-02-11 15:02:14 <@jbrooks:matrix.org> How's everyone doing today? 2025-02-11 15:02:20 <@siosm:matrix.org> !hi 2025-02-11 15:02:21 <@zodbot:fedora.im> Timothée Ravier (siosm) - he / him / his 2025-02-11 15:02:35 <@jbtrystram:matrix.org> !hi 2025-02-11 15:02:36 <@dustymabe:matrix.org> Good good. Hope you are Jason Brooks 2025-02-11 15:02:37 <@zodbot:fedora.im> Jean-Baptiste Trystram (jbtrystram) - he / him / his 2025-02-11 15:04:04 <@walters:fedora.im> this the first chat meeting right? Previously we were using https://etherpad.opensuse.org/p/bootc-initiative-meetings 2025-02-11 15:04:24 <@jbrooks:matrix.org> We had one other chat meeting: https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2025-01-28/fedora-bootc-initiative.2025-01-28-15.00.log.html 2025-02-11 15:04:36 <@jbrooks:matrix.org> two weeks ago 2025-02-11 15:05:06 <@walters:fedora.im> Ah OK cool. 2025-02-11 15:05:21 <@walters:fedora.im> I think we can get started? Is the first topic https://github.com/containers/buildah/issues/5952 ? 2025-02-11 15:05:33 <@jbrooks:matrix.org> Right 2025-02-11 15:05:40 <@walters:fedora.im> !topic https://github.com/containers/buildah/issues/5952 2025-02-11 15:06:36 <@walters:fedora.im> TL;DR previously buildah made it possible to write a Dockerfile that generated [chunked](https://github.com/ostreedev/ostree-rs-ext/issues/69) images, it got dropped in a security update, we are debating re-adding it 2025-02-11 15:07:08 <@walters:fedora.im> I guess from my PoV I'd say in the end we needed to support doing this outside of Dockerfile anyways too, so that just accelerated our plans for that 2025-02-11 15:07:46 <@dustymabe:matrix.org> I had originally asked to bring everyone together to discuss this before https://github.com/containers/buildah/pull/5975 existed to resolve the issue 2025-02-11 15:08:44 <@jlebon:fedora.im> glad to see there's a PR to re-add (a version of) it 2025-02-11 15:09:32 <@walters:fedora.im> I guess one question for the wider group is around the ergonomics of "rechunking post build" (as is doc'd here https://coreos.github.io/rpm-ostree/experimental-build-chunked-oci/ ) vs "rechunking in one podman build step"; they have quite different tradeoffs 2025-02-11 15:11:07 <@rsturla:fedora.im> What are the primary tradeoffs for each? On first glance, they appeared mostly the same, except for how the commands are invoked 2025-02-11 15:11:07 <@rsturla:fedora.im> Personally, I like the idea of doing this "rechunking" as part of the regular build. It allows users to use their existing application OCI image pipelines as-is, without needing to alter their workflows. 2025-02-11 15:11:07 <@rsturla:fedora.im> 2025-02-11 15:12:27 <@dustymabe:matrix.org> > "rechunking in one podman build step" 2025-02-11 15:12:27 <@dustymabe:matrix.org> 2025-02-11 15:12:27 <@dustymabe:matrix.org> I think this makes it quite attractive for new people to the process being able to try it out and also operationalize it. 2025-02-11 15:12:28 <@siosm:matrix.org> AFAIK: The in-Containerfile-build one requires podman/buildah to be the builder, the out-of-Containerfile-build one requires rpm-ostree on the host 2025-02-11 15:13:09 <@siosm:matrix.org> (I think we'll need both depending on the use cases) 2025-02-11 15:13:10 <@dustymabe:matrix.org> Colin Walters: could you summarize the "they have quite different tradeoffs" part? 2025-02-11 15:13:33 <@walters:fedora.im> It is possible to run it from a container too actually, I will try to make this clear. But yeah this problem exposes a lot of operational/cognitive complexity because especially in the "on the host" path you need to think about `-v /var/lib/containers:/var/lib/containers` etc 2025-02-11 15:13:54 <@walters:fedora.im> In our current CI flow I just installed rpm-ostree inside the quay.io/buildah:stable image... 2025-02-11 15:14:53 <@walters:fedora.im> But it may push us to more formally create a derived image...actually a minor annoyance here is we don't ship buildah in coreos/bootc (but we do ship podman) but the buildah image doesn't ship podman of course, so we need to have this podman/buildah abstraction 2025-02-11 15:15:49 <@walters:fedora.im> (tangentially related to that, longer term the only way to make this operation even remotely efficient would be to drive c/storage at a pretty low level to ensure we're e.g. reflinking instead of copying file content etc.) 2025-02-11 15:16:39 <@dustymabe:matrix.org> > "on the host" path you need to think about -v /var/lib/containers:/var/lib/containers etc 2025-02-11 15:16:39 <@dustymabe:matrix.org> 2025-02-11 15:16:39 <@dustymabe:matrix.org> I'm not the biggest fan of this option. Especially when we've already seen it work without something like this. 2025-02-11 15:16:51 <@walters:fedora.im> dustymabe: I think the summary is that if buildah/podman support this you *can* just do this as part of `podman build` and it seamlessly slots into any tools that wrap that (of which there are like, a lot) 2025-02-11 15:17:38 <@dustymabe:matrix.org> I'm interested in podman folks opinions here.. since you were all nice enough to join us here 👋 2025-02-11 15:17:52 <@dustymabe:matrix.org> I'm interested in podman folks opinions.. since you were all nice enough to join us here 👋 2025-02-11 15:18:38 <@mheon:matrix.org> nalind would be the best to comment here 2025-02-11 15:21:31 <@nalind:matrix.org> well i don't think we'll be able to turn support for [FROM things that aren't just image names] off any time soon, but the additional logic that we're going to have to add to try to avoid toc/tou symlink attacks in that content will involve a space tradeoff as we copy that content to a place where it can't be changed out from under us by a concurrently-running bad actor 2025-02-11 15:22:08 <@nalind:matrix.org> but yeah, i don't recommend the "mount /var/lib/containers from the host's /var/lib/containers" pattern 2025-02-11 15:24:08 <@walters:fedora.im> for `FROM oci:` I think we'd generally always be safe against concurrent mutation? 2025-02-11 15:24:52 <@nalind:matrix.org> we have to pass that location through a few API layers to the image library, which we depend on elsewhere to follow symlinks when it's reading the contents of the layout 2025-02-11 15:25:01 <@nalind:matrix.org> but here, we kind of want to not 2025-02-11 15:25:24 <@jlebon:fedora.im> nalind: if i look at the tests added in https://github.com/containers/buildah/pull/5975/files, i see e.g. `FROM oci-archive:archive2.tar` which is quite similar to what we had. do you expect that to change before the PR merges? 2025-02-11 15:26:07 <@walters:fedora.im> In https://docs.rs/ocidir/latest/ocidir/ we use cap-std to constrain everything to the oci subdirectory 2025-02-11 15:26:10 <@nalind:matrix.org> no, i don't expect to break that. that test is there because i expect it to pass when it's marked as ready for review/merge 2025-02-11 15:26:59 <@walters:fedora.im> (cap-std here == openat2(, RESOLVE_BENEATH) 2025-02-11 15:28:05 <@walters:fedora.im> anyways overall I'd summarize this as: that PR will continue, but we'll also just invest in rechunking outside of Containerfile for now and mainly am to "productize" that more 2025-02-11 15:28:13 <@walters:fedora.im> anyways overall I'd summarize this as: that PR will continue, but we'll also just invest in rechunking outside of Containerfile for now and mainly aim to "productize" that more 2025-02-11 15:28:49 <@nalind:matrix.org> in that other context, i actually do depend on the not-beneath behavior 2025-02-11 15:29:50 <@walters:fedora.im> ok, we can probably debate those details in that PR I guess 2025-02-11 15:30:21 <@walters:fedora.im> I don't have more on this topic 2025-02-11 15:30:38 <@jbrooks:matrix.org> Anything to follow up on on this in future meetings? 2025-02-11 15:31:38 <@jbrooks:matrix.org> Also, this meeting is 30 min, and we're at time, I don't know if having it via chat now increases anyone's length wishes 2025-02-11 15:32:12 <@dustymabe:matrix.org> for the fcos meeting we have it set to an hour 2025-02-11 15:32:21 <@dustymabe:matrix.org> for matrix meetings 2025-02-11 15:32:26 <@jlebon:fedora.im> I think one thing to emphasize is that most people will not need to rechunk or worry about this. For those that do want to, I think having access to both workflows (within podman build, and outside) is valuable 2025-02-11 15:32:28 <@dustymabe:matrix.org> if we run out of topics we close it out 2025-02-11 15:32:50 <@dustymabe:matrix.org> Thank you container folks for coming! 2025-02-11 15:33:06 <@dustymabe:matrix.org> nalind++ Matt Heon++ Brent Baude++ 2025-02-11 15:33:07 <@zodbot:fedora.im> No Fedora Accounts users have the @nalind:matrix.org Matrix Account defined 2025-02-11 15:33:09 <@dustymabe:matrix.org> did I miss anyone? 2025-02-11 15:34:10 <@jbrooks:matrix.org> OK, let's close this one off, and I'll ask in https://matrix.to/#/#bootc:fedoraproject.org for topics for next week 2025-02-11 15:34:36 <@jbrooks:matrix.org> !endmeeting