Meeting started at 2025-02-11 15:00:34 UTC

The Meeting name is 'fedora_bootc_meeting'

!hi

Dusty Mabe (dustymabe) - he / him / his

!hi

None (rsturla)

!hi

Colin Walters (walters)

!hi jasonbrooks

Jason Brooks (jasonbrooks) - he / him / his

!hi

Hristo Marinov (hricky) - he / him / his

!hi

!hi

None (jlebon)

Joseph Marrero (jmarrero)

!hi

No Fedora Accounts users have the @bbaude:matrix.org Matrix Account defined

How's everyone doing today?

!hi

Timothée Ravier (siosm) - he / him / his

!hi

Good good. Hope you are Jason Brooks

Jean-Baptiste Trystram (jbtrystram) - he / him / his

this the first chat meeting right? Previously we were using https://etherpad.opensuse.org/p/bootc-initiative-meetings

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

two weeks ago

Ah OK cool.

I think we can get started? Is the first topic https://github.com/containers/buildah/issues/5952 ?

Right

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

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

I had originally asked to bring everyone together to discuss this before https://github.com/containers/buildah/pull/5975 existed to resolve the issue

glad to see there's a PR to re-add (a version of) it

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

What are the primary tradeoffs for each? On first glance, they appeared mostly the same, except for how the commands are invoked

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.

> "rechunking in one podman build step"

I think this makes it quite attractive for new people to the process being able to try it out and also operationalize it.

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

(I think we'll need both depending on the use cases)

Colin Walters: could you summarize the "they have quite different tradeoffs" part?

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

In our current CI flow I just installed rpm-ostree inside the quay.io/buildah:stable image...

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

(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.)

> "on the host" path you need to think about -v /var/lib/containers:/var/lib/containers etc

I'm not the biggest fan of this option. Especially when we've already seen it work without something like this.

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)

I'm interested in podman folks opinions here.. since you were all nice enough to join us here 👋

I'm interested in podman folks opinions.. since you were all nice enough to join us here 👋

nalind would be the best to comment here

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

but yeah, i don't recommend the "mount /var/lib/containers from the host's /var/lib/containers" pattern

for `FROM oci:` I think we'd generally always be safe against concurrent mutation?

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

but here, we kind of want to not

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?

In https://docs.rs/ocidir/latest/ocidir/ we use cap-std to constrain everything to the oci subdirectory

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

(cap-std here == openat2(, RESOLVE_BENEATH)

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

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

in that other context, i actually do depend on the not-beneath behavior

ok, we can probably debate those details in that PR I guess

I don't have more on this topic

Anything to follow up on on this in future meetings?

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

for the fcos meeting we have it set to an hour

for matrix meetings

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

if we run out of topics we close it out

Thank you container folks for coming!

nalind++ Matt Heon++ Brent Baude++

No Fedora Accounts users have the @nalind:matrix.org Matrix Account defined

did I miss anyone?

OK, let's close this one off, and I'll ask in https://matrix.to/#/#bootc:fedoraproject.org for topics for next week