Setup cgroups handling

[saschagrunert]

The details of the implementation have to be defined.

[Klaven]

I would love to help with this aspect, Though as I don't have the experience of implementing this in other projects so I am afraid I could do no more then assist. Please let me know if there is something with regards to this that I could help with!

Would we want to make the cgroup implementation it's own crate? was just thinking some of the base work with dealing with cgroups could be useful in other rust projects as well as a nice separation? That is if we move too a "workspace" type of project.

[saschagrunert]

I would love to help with this aspect, Though as I don't have the experience of implementing this in other projects so I am afraid I could do no more then assist.

Thanks! I think a good reference where we can start is the cgroup implementation of CRI-O: https://github.com/cri-o/cri-o/blob/master/internal/config/cgmgr/cgmgr.go

Nevertheless, some architectural design decisions have to be made. We probably want to support cgroups v2 and rootless execution out of the box, so I’m not sure which path to take right now. Messing around with the cgroups drivers between the kubelet and the runtime is a common issue when setting up a Kubernetes cluster. I’d like to avoid that.

Please let me know if there is something with regards to this that I could help with!

Thanks! I hope that @giuseppe has some thoughts on the topic.

Would we want to make the cgroup implementation it's own crate? was just thinking some of the base work with dealing with cgroups could be useful in other rust projects as well as a nice separation? That is if we move too a "workspace" type of project.

To simplify the build process I’d prefer sticking to modules for now. We can easily make them own crates later on if the implementation is decoupled enough. Maintaining public APIs makes it harder for us to develop the MVP.