rhinstaller
Require podman
This is prep for supporting bootc: https://github.com/rhinstaller/anaconda/discussions/5197
A big part of the idea with bootc is that with bootc install, a container image can install itself:
https://github.com/containers/bootc/blob/main/docs/install.md
This will longer term replace the ostreecontainer verb.
However even beyond that, having podman on the (smaller netinst, as well as bigger DVD) installer ISO will just generally be useful for a variety of things. For example, one can now do e.g.:
%post --no-chroot
podman run ...
Which unblocks a lot of things! (Some of which admittedly will be hacks, but that's what a lot of %post is...)
Having a container runtime in the Live ISO is a very key feature of the Fedora CoreOS (and RHEL CoreOS) Live ISOs, and this brings Anaconda closer to parity too.
Hi @cgwalters looks good to me. However, don't we want to add the new dependency together with the new code?
Just to be clear, I'm not opposed to merge this if it will improve your life even like this.
@KKoukiou do you know why the icon is broken on pixel tests? I don't think it's happening because of these change.
Hi @cgwalters looks good to me. However, don't we want to add the new dependency together with the new code?
Yep, up to you! Though as I said in the commit message I think it'd likely be very generally useful to be able to run podman as part of the installation environment today; right?
Hi @cgwalters looks good to me. However, don't we want to add the new dependency together with the new code?
Yep, up to you! Though as I said in the commit message I think it'd likely be very generally useful to be able to run
podmanas part of the installation environment today; right?
I'm thinking we might have to bump the advertised RAM requirements a bit or add a disclaimer there as I would guess that running a container could result in more resource usage. Like, of course it was already possible to hit OOM with regular scriptlets if you are crazy enough, but running a container will likely move the baseline.
Adding podman itself will not run a containers so until we do that (bootc support) we probably don't want to raise the requirements.
Images built based on commit 036646c155a46057a91612b65b506c7e20d6ee5a:
boot.iso: success
Download the images from the bottom of the job status page.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I did some testing and this will make the ISO bigger by 20MB. From 763MB to 783MB size of the ISO.
@M4rtinK, @KKoukiou, @bcl I wonder if this is the issue or not
Currently the ostree-container stack depends on skopeo, which is 27M. We've talked in https://github.com/containers/bootc/issues/81 about supporting using podman for this too (it'd be an obvious step) in which case it's likely skopeo could drop out - that'd likely make this a much smaller total size increase.
@AdamWill I wonder how we should proceed to find out if the size change is an issue. Do you remember what is the process?
Currently the ostree-container stack depends on
skopeo, which is 27M.
@jkonecny12 Btw. our dependency on skopeo is defined in the anaconda-install-img-deps meta package. This pull request adds podman to the anaconda-core package. This means that the impact is going to be broader (not just a boot.iso) unless this is unintentional.
I can do a scratch build and run it through openQA to see the size change for an x86_64 netinst image.
although, building your own netinst image is pretty easy (much easier than live image) - basically you do setenforce Permissive then lorax -p Fedora -v Rawhide -r Rawhide --repo=/etc/yum.repos.d/fedora-rawhide.repo --repo=/etc/yum.repos.d/happyassassin-side.repo --rootfs-size=3 --squashfs-only ./results , where the second repo file is a repo definition pointing to the repo where you've stashed whatever different package(s) you want to be in the build.
our dependency on skopeo is defined in the anaconda-install-img-deps meta package. This pull request adds podman to the anaconda-core package. This means that the impact is going to be broader (not just a boot.iso) unless this is unintentional.
AIUI a (the?) difference is that dependencies of anaconda.rpm will also show up on e.g. the Fedora Workstation live ISO? In that case, podman is already there, so I don't think that's a concern right?
@cgwalters if we do it this way, then it's dependency of anaconda-core package. That means that everywhere you would install Anaconda (or something dragging in Anaconda) would also install podman. In other words, it will impact every deliverable with Anaconda or Inital Setup (for example ARM board deployment).
For Anaconda I think this is correct, however, I'm not that sure about Initial Setup case. That could raise more troubles.
@AdamWill I already did the comparation by our automation and local build from the latest Anaconda sources: https://github.com/rhinstaller/anaconda/blob/master/dockerfile/anaconda-iso-creator/lorax-build#L43
However, yeah, maybe we should also try to do this without our modifications to be sure.
@AdamWill verified in the latest fedora Rawhide container: Without podman:
[root@e226d6855e3c build]# ls -lh just-rawhide/results/images/boot.iso
-rw-r--r--. 1 root root 744M Nov 22 08:51 just-rawhide/results/images/boot.iso
With podman:
[root@e226d6855e3c build]# ls -lh with-podman/results/images/boot.iso
-rw-r--r--. 1 root root 764M Nov 22 09:31 with-podman/results/images/boot.iso
So the size increase is 20 MB as mentioned above. Now I wonder who to ask or where to verify that such a size increase is fine.
Also we might need to move this to anaconda-install-img-deps instead of core because of the Inital Setup use-case.
@jkonecny12 Maybe I am missing something, but I don't understand the reasoning behind having a hard dependency on podman via anaconda-core. The installer is able to run without it. I think it should be required by one of our meta packages: anaconda-install-env-deps or anaconda-install-img-deps.
Yes, I agree it should be part of other package. However, the main question here is if the 20MB of image size is an issue or no, that will not change with the move of the package.
Well, there isn't really a simple answer to that, it's a judgment call. 20M is a big chunk, relatively speaking, so the functionality bonus should be quite large to justify it. This will make it very difficult to keep netinst images under the 700M size limit we still have for x86_64 at present (though possibly removing yelp will help counterbalance that for now).
Is there any way we could do a podman-core package which strips it (and its dependencies) down to a really minimal set for what the anaconda use case needs, or anything like that?
In the long term at least, having podman and the bootc kickstart verb will let us move closer to dropping rpm-ostree out of the set of dependencies.
Is there any way we could do a podman-core package which strips it (and its dependencies) down to a really minimal set for what the anaconda use case needs, or anything like that?
That already happens when Recommends is turned off right?
@AdamWill I wonder if I should create a FESCO ticket to get the final decision about this?
@cgwalters IIRC lorax is not installing Recommends at all so it should be stripped down already.
so, as things stand, we're already oversize for the netinsts for current Rawhide, and that's after yelp removal (that did reduce size a bit, but not enough to get it back under the limits after the most recent linux-firmware expansion). I think I'm going to have to file a ticket somewhere about increasing the max sizes, as I'm not sure we're going to be able to get back under 700M at this point.
Seems that it was before that. New results:
no podman:
[root@66b74a6285d2 /]# ls -lh results-bare/images/boot.iso
-rw-r--r--. 1 root root 701M Dec 5 16:55 results-bare/images/boot.iso
with this PR:
[root@675768cf12d9 /]# ls -lh results-podman/images/boot.iso
-rw-r--r--. 1 root root 721M Dec 5 17:22 results-podman/images/boot.iso