Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setup cgroups handling #60

Open
saschagrunert opened this issue Sep 15, 2020 · 2 comments
Open

Setup cgroups handling #60

saschagrunert opened this issue Sep 15, 2020 · 2 comments
Projects

Comments

@saschagrunert
Copy link
Member

The details of the implementation have to be defined.

@saschagrunert saschagrunert created this issue from a note in project (To do) Sep 15, 2020
@Klaven
Copy link
Contributor

Klaven commented Sep 19, 2020

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
project
  
To do
Development

No branches or pull requests

2 participants