Hi, I created a snap for crun compiled with wasmedge support. Crun is a oci runtime that is usually used by a cri (container runtime interface) like containerd or CRI-O to start containers.
This snap should be used by a microk8s plugin to enable WebAssembly Images. The main reason why strict confinement is not working in this scenaro is that crun needs to write to a state folder of containerd which is located at $SNAP_COMMON/run/containerd/ of the microk8s snap.
We will work towards a solution to run with strict confinement in the future.
If one snap needs to provide content for another snap then you should look at using a content interface - microk8s could provide the interface which crun could plug and then dump the state into it. Then (based on the description above) you shouldn’t need classic confinement. https://snapcraft.io/docs/content-interface
Thanks for the response, I already looked at the content plugin. The problem is that it is not about content that is passed from one to another. Containerd and crun maintain the state of the containers together and since the CRI passes the absolute path to the oci runtime, the state folder can’t be mounted in different paths. Which is the case with the content plugin as far as I understand it.
So both snaps need to access the same absolute path to read and write. Is there an interface for that?
@alexmurray or would the system-files interface be a better choice?
I still don’t think I entirely understand the use-case here - in my head a content interface still seems like it should be appropriate - can you please try and explain this more so I can understand it better? Thanks.
Sure,
MicroK8s is a Kubernetes distribution and they added a plugin mechanism for the next release (1.24). I created a plugin that changes the oci runtime from runc to crun. The oci runtime is a command line tool that executes container and is called by the CRI which is containerd for microk8s.
Containerd has a configuration called state. That is the folder where the container states are stored. So contaienrd needs to have read/write access on that folder.
Now the problem comes in, containerd passes the absolute path to the state folder to crun:
- crun is installed by the plugin as a separate snap,
crun-wasmedge.
- crun gets the path
/var/snap/microk8s/common/run/containerd as state folder from containerd which is not accessible in strict confinement
What I tried with the content plugin was to share the state folder, which then was available under /var/snap/crun-wasmedge/common/run/containerd but that is not the path that containerd hands over to crun.
To sum it up, I need a folder where both snaps have read/write access and it needs to be available under the same absolute path.
@kjackal hey, since this is related to microk8s are you able to provide any guidance here? Thanks.
I suspect the interface between crun and the rest of the world might not be that well defined and this does not align with what is expected from snap interfaces. Contrary to deb packages snaps have the benefit of packaging an application and all of its dependencies in a single fat package. Maybe crun is not a good candidate for a snap and it would be best to package it along with containerd.
For the case of MicroK8s, @0xe282b0 have you tried to place crun in the addon or install it (ie call install.sh) from the enable script?
Hi @kjackal, I just followed the Kata runtime as example (https://github.com/canonical/microk8s-community-addons/blob/main/addons/kata/enable#L100)
If snap is not the desired way of distributing add-on dependencies, I could download it directly from Github.
Hi @0xe282b0, given the feedback from this thread, do you still wish to proceed with this request?
@rayveldkamp, I think we can put down this request.
Thanks for the update @0xe282b0 - please feel free to reach out if things change in the future, and you want to pursue a snap for this again, and we’ll add it back to our queue.
