Currently, we ship docker in the base image for Fedora Atomic Host. With the release of CRI-O, as well as the issues around docker versions, one possible solution is to ship only runc with the base Atomic Host, and make container runtimes installable as system containers. If we don't move docker to a system container, there's a strong argument to also ship CRI-O as part of the base image.
Arguments in favor of System Containers for CRs:
Arguments against using System Containers for CRs:
One bifurcation I see here is that larger scale systems do want decoupled host upgrades ("I want to yum update/rpm-ostree upgrade without upgrading Kubernetes/OpenShift").
But for smaller scale systems ("I have a home server") decoupling the container runtime feels like a lot of overhead. But eh, we can probably fix that.
I think my vote here is to focus on system containers for Kube/OpenShift first... which actually doesn't answer the question.
If we're going to default to containerized cri-o, I think we need to fix things upstream. Right now the upstream docs follow the (IMO anti-pattern) of installing build dependencies on a host and doing a sudo make install. https://github.com/kubernetes-incubator/cri-o
sudo make install
With the latest FAH rpm-ostree install cri-o seems to work fine FWIW.
rpm-ostree install cri-o
I've been working on a writeup using the crio system container from https://github.com/projectatomic/atomic-system-containers.
Metadata Update from @dustymabe:
- Issue tagged with: meeting
I'd like to see us use System Containers for runtimes. While I agree that's different that what users currently expect it's due to us giving the expectation that there is a runtime and it is docker. Having runtime be something that is installed as a System Container as one of the first steps (or maybe part of first boot via parameter) seems sane to me.
We use atomic hosts in two different ways in production and our users follow two different usage patterns.
The user has short living clusters (of atomic hosts) and recreates often (compute intensive workloads) [These users expect to have the latest stable version when they create a new cluster and they don't necessarily care about upgrading. However, upgrading is a nice-to-have feature for them.]
The user has long running clusters for production services [these users want a relatively new version of docker (6 months old), upgrading is very important for them]
As service provider who offer atomic hosts I would be happy with running the runtimes in system containers. So +1 on all arguments in favor. Regarding the arguments against: Two steps to install a container runtime is reasonable. I think the space load is compensated by having more options and I don't think it is a big problem for usage on public/private clouds. The last two can be tricky but are also giving flexibility. However it would be nice to be able to select the version of the runtime eg atomic install cri-o:1.x or atomic install docker:17.09 even a newer release is available. It is more clear what you get instead of atomic install docker:latest.
Finally, having a docke-ce system container would be really nice to have.
When are we expecting the survey to close?
Earlier in the week @jberkus noted he was working on this and should have results late this week or early next.
Survey results: https://docs.google.com/document/d/1aC8uthOMrTLiYK3l5muUVKDnOO7Rich2JxJ0sd4LJ6o/edit?usp=sharing
So, we discussed this at the Fedora Atomic WG meeting:
Our decision was to NOT remove docker from the base OStree in the Fedora 27/28 timeline, but to instead:
closing this based on result in previous comment. will revisit when necessary in the future.
Metadata Update from @dustymabe:
- Issue untagged with: meeting
- Issue status updated to: Closed (was: Open)
to comment on this ticket.