Creating fedora container runtime as seen in flatpak module #72

JayDoubleu · 2021-10-16T16:03:52Z

JayDoubleu
Oct 16, 2021

Fedora flatpaks are built using the fedora base image with sensible defaults found here:

Is it work creating one based on that to save some disk space when building podenv application based on fedora ?
Looks like dhall could handle that YAML conversion directly from flatpak-common.yaml ?

TristanCacqueray · 2021-10-16T19:52:03Z

TristanCacqueray
Oct 16, 2021
Maintainer

Diskspace is definitely an issue with container images and I wonder if using such fat image would really help. Here are some options and future improvements to address that issue:

First you can simply update your local copy of an upstream image, then further build would share the updated content. Here is an example:

function buildah_install {
  IMG=$1; shift; mkdir -p ~/.cache/buildah-dnf
  CTX=$(buildah from --pull-never --volume ~/.cache/buildah-dnf/:/var/cache/dnf:Z $IMG)
  buildah run $CTX dnf install -y $@
  buildah commit --rm $CTX $IMG
}
buildah_install registry.fedoraproject.org/fedora:latest  mesa-dri-drivers gtk4

You can also setup a custom image with podenv, and assign it to the relevant applications, here is the documentation for that: https://github.com/podenv/podenv/blob/main/docs/howtos/image.md

Also, note that podenv can do inplace update, e.g. when running podenv --update my-app, it should rebuild the image using from my-app run dnf update -y. But I think using such Containerfile based runtime is not great with regard to disk space and efficiency.

One major improvement I'd like to investigate is to use libostree instead of containers/image. That way we could use rpm-ostree configuration directly inplace of Containerfile, or perhaps even use existing flatpak image, but with podman. I think this is the best solution moving forward, and we just need to figure out how to setup the rootfs so that podman can use it (e.g. ostree checkout before podman run --rootfs /ostree/...)

Another alternative would be to simply support a rootfs runtime, and let the user manage it, e.g. using something similar to debootstrap.

In any case, note that podenv application runtime is an union (e.g. sum type) defined as: https://github.com/podenv/hub/blob/main/schemas/Runtime.dhall . The plan being to be able to support other runtimes, for example, ideally, it could be defined as:

< Image : Text
| Nix : Expr
| Container : Containerfile
| RootFS : FilePath
| Ostree : Commit
| RpmOstree : Configuration
>

Where Ostree would be the main new primitive (similar to Image), and RpmOstree would support loading such configuration: https://pagure.io/workstation-ostree-config/blob/main/f/fedora-common-ostree.yaml .

1 reply

JayDoubleu Oct 18, 2021
Author

Thanks @TristanCacqueray for my use case i'll create custom image, likely from registry.fedoraproject.org/f35/flatpak-runtime mentioned by Jens. Having the ability to use ostree would be a great addition. I intend to use podenv mainly for custom development environments which would differ only slightly from each other likely by some volumes + some GUI apps done the same way for isolation.

I tried running podman with rootfs from fedora runtime ostree --repo=repo -U checkout fedora:runtime/org.fedoraproject.Platform/x86_64/f35 but podman just hangs.

TristanCacqueray · 2021-10-16T19:56:10Z

TristanCacqueray
Oct 16, 2021
Maintainer

For the second question, we can implement modulemd or (rpmostree yaml) configuration using dhall expressions, either through automatic conversion with yaml-to-dhall, or through a proper binding (for example here is the one for ansible: https://github.com/softwarefactory-project/dhall-ansible ).

0 replies

juhp · 2021-10-18T09:53:17Z

juhp
Oct 18, 2021

Somewhat in the same vein, I think it would be cool/fun to be able
to create a "container" by bind mounting parts of the host fs,
but that might be outside the scope of podenv or not, I dunno.
Well it would probably need some minimal container to bootstrap?

This way a user could run the host system's programs outside their home environment say for example.

2 replies

TristanCacqueray Oct 18, 2021
Maintainer

Oh yes, that could be a runtime unit, e.g. < Host >, which would use -v /etc:/etc -v /usr/lib:/lib -v /usr/lib64:/lib64 -v /usr/bin:/bin --rootfs /tmp/empty instead of an image.

TristanCacqueray Apr 27, 2022
Maintainer

With #99 , there is a new Rootfs runtime which can be used to start a bubblewrap powered container on a local directory. This should be seamless with regards to podman.

juhp · 2021-10-18T11:17:11Z

juhp
Oct 18, 2021

It is probably worth mentioning that flatpak also supports OCI runtimes and app images nowadays, in addition to ostree.

eg registry.fedoraproject.org/f35/flatpak-runtime

0 replies

TristanCacqueray · 2021-10-18T12:30:05Z

TristanCacqueray
Oct 18, 2021
Maintainer

I wonder how flatpak layers those OCI runtimes. This week end I tried using flatpak for blender (as the fedora rpm doesn't seem to support ffmpeg) and I discovered it can run in --user mode, which is similar to podman rootless mode. To run the flatpak:

$ flatpak --user remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
$ flatpak --user install flathub org.blender.Blender
$ flatpak --user run org.blender.Blender

This creates a local ostree repository in ~/.local/share/flatpak/repo, which I tried to use to assemble the application rootfs, unfortunately without success. Here are some notes:

$ cd ~/.local/share/flatpak
$ ostree --repo=repo refs
$ ostree --repo=repo -U checkout deploy/app/org.blender.Blender/x86_64/stable ./test-rootfs

This create test-rootfs/files which seems to contain the application layer, there is the blender binary, but not runtime (e.g. no libc).
Adding -vv to the flatpak run reveals all the bind mounts that are used to create the bwrap environment, so in theory we should be able to use the flatpak ostree repos directly, but I am not sure how flatpak compose the runtimes. For example we can't just checkout all the refs, some needs to be attached at a different location, for example this ref deploy/runtime/org.freedesktop.Platform.ffmpeg-full/x86_64/20.08 does not put the .so files in a lib directory.

I think it would be interesting to dig more the flatpak internals and evaluates how complicated it is to recreate the bwrap mount location manually. Perhaps it would be useful to contribute a flatpak --show option upstream to display the full bwarp command of a flatpak app.

Another solution would be to wrap flatpak --user with podenv, e.g. by finding equivalent flatpak command argument that podenv pass to podman.

0 replies

TristanCacqueray · 2021-11-15T21:31:21Z

TristanCacqueray
Nov 15, 2021
Maintainer

Note that until we can cleanly compose the image using ostree reference, here is a solution implemented in the hub where the applications can now fedora.useGraphic to benefit from a common layer loaded with gtk and dri-drivers: podenv/hub#43

0 replies

Creating fedora container runtime as seen in flatpak module #72

Uh oh!

Uh oh!

JayDoubleu Oct 16, 2021

Replies: 6 comments · 3 replies

Uh oh!

Uh oh!

TristanCacqueray Oct 16, 2021 Maintainer

Uh oh!

JayDoubleu Oct 18, 2021 Author

Uh oh!

TristanCacqueray Oct 16, 2021 Maintainer

Uh oh!

Uh oh!

juhp Oct 18, 2021

Uh oh!

TristanCacqueray Oct 18, 2021 Maintainer

Uh oh!

TristanCacqueray Apr 27, 2022 Maintainer

Uh oh!

juhp Oct 18, 2021

Uh oh!

TristanCacqueray Oct 18, 2021 Maintainer

Uh oh!

TristanCacqueray Nov 15, 2021 Maintainer

JayDoubleu
Oct 16, 2021

Replies: 6 comments 3 replies

TristanCacqueray
Oct 16, 2021
Maintainer

JayDoubleu Oct 18, 2021
Author

TristanCacqueray
Oct 16, 2021
Maintainer

juhp
Oct 18, 2021

TristanCacqueray Oct 18, 2021
Maintainer

TristanCacqueray Apr 27, 2022
Maintainer

juhp
Oct 18, 2021

TristanCacqueray
Oct 18, 2021
Maintainer

TristanCacqueray
Nov 15, 2021
Maintainer