I think one way of doing this is to copy the CRI-O clients (crioctl, kpod, something else?) to the host so that they can be accessed directly without requiring "atomic exec".

I am very biased on this topic but I don't see the point of adding another component to the host image when it works very well from a container. Also, if the need arises we have package layering.

In particular for CRI-O there are different versions that follow the Kubernetes/OpenShift releases, so which one would be added to the base image?

I think one way of doing this is to copy the CRI-O clients (crioctl, kpod, something else?) to the host so that they can be accessed directly without requiring "atomic exec".

I am very biased on this topic but I don't see the point of adding another component to the host image when it works very well from a container. Also, if the need arises we have package layering.

I'm with you on that. The worry is around it being as easy to access as docker since docker is going to remain in the base (though folks who need a different version for OpenShift or other things will continue to use system containers). We don't want to discourage the use of docker at all, but we also don't want to discourage the use of cri-o because you have to jump through hoops.

Added meeting label to discuss in next WG.

My high level feeling is:

Two years from now, for Atomic Host we should basically be a minimal install; sshd, kernel, systemd, and then finally atomic and rpm-ostree. Hopefully by that time we'll have fleshed out the system containers story more, and also have "live" package layering. I hope we'll also have e.g. changed oc cluster up to not require Docker on the host.

What we do in the short term is a harder problem, as well as how we handle transitions - trying to drop docker would be a large and painful change without a lot of work.

Some of the discussion around this (this is edited):

11:45:27     dwalsh | Yes I think adding podman once it stabilizes is a good idea.
11:46:12    ashcrow | It sounds like it's not ready just yet
11:46:19  dustymabe | still, the current question is related to should we include podman, not should we remove docker
11:46:30    ashcrow | but once it is, assuming it's not a massive size hit, I think it makes sense to add it
11:46:51       misc | ashcrow: massive size hit being around how much ?
11:47:39     dwalsh | 47 Megabytes right now.
11:47:41    ashcrow | misc: that is subjective, but IMHO it should be no bigger than docker if possible
11:48:53     dwalsh | Docker files are currently 46
11:48:57    ashcrow | close enough
11:49:00  dustymabe | 1. add podman
11:49:11  dustymabe | 2. make docker not start by default but be socket activated
11:49:18     dwalsh | Yes I would lets us figure out how well it goes over the next month or so.
11:49:22  dustymabe | that way the user chooses if they want docker running or not
11:52:37  dustymabe | we close it out and say "no to cri-o"
11:53:08  dustymabe | and then open a new ticket for evaluating podman in a few months
11:53:15  dustymabe | with the steps laid out above
11:56:20  dustymabe | #action dustymabe to create new ticket for evaluating podman in a few months

We will not add cri-o to base. podman will be looked at in a ticket opened by @dustymabe.