Try to make the podman driver less "experimental", for podman version 3.0

[afbjorklund]

There is a new version of podman being prepared: v3.0.0

• https://github.com/containers/podman/tree/v3.0

• https://github.com/containers/podman/releases/tag/v3.0.0-rc1

This is the release track that will go into next RHEL (previously based on first 1.6.4 and then 2.0.5)

• https://github.com/containers/podman/tree/v1.6.4-rhel

• https://github.com/containers/podman/tree/v2.0.5-rhel

Hopefully this means that the podman driver is finally stable enough to be made non-experimental.

---

The main features are support for the docker socket and for docker compose, so nothing breaking ?

Support for podman has already been merged, and both KIC and ISO are currently running v2.2.1

From the "Podman v3.0.0-rc1 is now available for testing" post:

We are anticipating a final release in several weeks. We will publish
a second release candidate next Monday, and if no major bugs are
identified, the 3.0.0 final release will be the subsequent Monday,
February 1.

[afbjorklund]

Preferrably this should be tested on Fedora, and by using the container runtime CRI-O...

Note that it has some other quirks, like using selinux + cgroups v2 and running on "btrfs":

• https://fedoraproject.org/wiki/Changes/CGroupsV2

• https://fedoraproject.org/wiki/Changes/BtrfsByDefault

The CentOS Linux distribution has now been deprecated (ends 2021-12-31, no version 9)

So this means Fedora is the primary testing target, before Red Hat Enterprise Linux (RHEL).

• https://blog.centos.org/2020/12/future-is-centos-stream/

• https://blog.centos.org/2020/12/how-rhel-is-made/

---

See this workaround for btrfs: #10182 (comment)

It is also possible to use ext4, or xfs, during install.

[afbjorklund]

Note: You can also run Fedora with cgroups v1, ext4 and "moby-engine" (19.03).

• https://fedoramagazine.org/docker-and-fedora-32/
• https://docs.docker.com/engine/install/fedora/

"But where is the fun in that"

The main reason for supporting podman and cri-o is for RHEL

[afbjorklund]

Minikube seemed to be working more or less OK with podman 3.0.0-rc2.

But needless to say there were bugs, and we now have a RC3 instead...

https://github.com/containers/podman/releases/tag/v3.0.0-rc3

More testing with minikube is needed, especially on Fedora (or on RHEL)

[afbjorklund]

Podman 3.0 has been released: https://github.com/containers/podman/releases/tag/v3.0.0

Should be compatible with Podman 2.1 and 2.2 as well, but not with the earlier 1.9 and 2.0.

[afbjorklund]

@medya said:

how about we add Funcitonal Test on Github Action for Podman before we bump up the priority?

[efussi]

FWIW, I upgraded to podman version 3.0 and tried to start minikube, but it failed:

$ minikube start --driver podman
😄  minikube v1.17.1 on Ubuntu 20.04 (vbox/amd64)
✨  Using the podman (experimental) driver based on user configuration
👍  Starting control plane node minikube in cluster minikube
🔥  Creating podman container (CPUs=2, Memory=6144MB) ...
✋  Stopping node "minikube"  ...
🔥  Deleting "minikube" in podman ...
🤦  StartHost failed, but will try again: creating host: create: creating: create kic node: container name "minikube": log: 2021-02-15T10:50:15.670134241+01:00 + dmesg
2021-02-15T10:50:15.670216253+01:00 + tail
2021-02-15T10:50:15.675879557+01:00 + sleep 1
2021-02-15T10:50:16.676836568+01:00 + exit 30: container exited unexpectedly
🔥  Creating podman container (CPUs=2, Memory=6144MB) ...
😿  Failed to start podman container. Running "minikube delete" may fix it: creating host: create: creating: setting up container node: creating volume for minikube container: sudo -n podman volume create minikube --label name.minikube.sigs.k8s.io=minikube --label created_by.minikube.sigs.k8s.io=true: exit status 125
stdout:

stderr:
Error: volume with name minikube already exists: volume already exists


❌  Exiting due to GUEST_PROVISION: Failed to start host: creating host: create: creating: setting up container node: creating volume for minikube container: sudo -n podman volume create minikube --label name.minikube.sigs.k8s.io=minikube --label created_by.minikube.sigs.k8s.io=true: exit status 125

Seems the restart tries to create a volume that still exists from the earlier attempt (I ran podman system reset and minikube delete --all before minikube start --driver podman).

[afbjorklund]

You need to run a version that includes PR #10435 (i.e. latest/greatest)

Or just sudo podman volume rm minikube to clean up after the old one

[afbjorklund]

Works OK with Podman 3.0.1 now