Open luxas opened 5 years ago
roger!
@stealthybox what we have planned now conflicts with this issue. could you please remove v0.7.0
milestone out of this one.
Why does it conflict? I think we should try to do forward-fixes instead of keeping the older code
the docker runtime makes it a breeze experience for Ignite users but it's still a bit difficult for the containerd runtime to have on-par UX.
If a goal is to have the best UX for people to try VMs with Ignite, let's not too hurry to remove docker :-)
Alternatively, if we could ship containerd
along with ignited
, and the UX is improved. We could finally remove docker dependency. WDYT? cc @luxas @twelho @stealthybox
ref #399
I'm less worried about containerd as the runtime now that #411 copes well with different versions and installs.
docker+docker-bridge
works OOTB for many users.
docker+cni
works except for #393.
containerd+cni
is currently not working -- this is our next priority.
Once everything with CNI is fixed and we have packaging and installation polished, I think we can begin to consider this.
It's worth noting that ignite leaves behind a lot of containers right now when we hit bugs managing ignite vm state. This causes ignite to orphan containers and dm snapshots.
The ctr
CLI is necessary to clean these up in containerd. ctr
is an undocumented, hacky dev tool that is not widely known.
docker
has a supported, versioned, CLI, and people know how to use it.
Implementing ignite clean
using the containerd API's and dmsetup remove_all
would probably be necessary.
As a user I don't know how to manually cleanup after CNI.
Adding another CNI issue: #423
Also see #436 regarding CNI startup time
Fully base Ignite on containerd/CNI-only, and get rid of the extra docker imports. Will result in a cleaner, leaner and more understandable codebase. cc @chanwit