I’m finally back from the LinuxWorld San Francisco. The event was great — I met a lot of interesting people, distributed about hundred of OpenVZ DVDs, saw that Motorola Linux-powered phone, and even won a Slashdot Beanbag! The only disappointing fact is OpenVZ has no booth of its own, so nobody saw OpenVZ was there.
But while I was having fun, our guys did a great job posting sets of User Beancounter (UBC) patches and the network namespaces patches for a review. It looks like UBC stuff caused quite a long discussion. Some valid concerns were raised (and will be addressed).
The other thing is, besides UBC, there is also CKRM (Class-based Kernel Resource Management) out there, which basically has the same (or perhaps broader) goals. As Alan Cox puts it, “[...] OpenVZ has all the controls and resource managers we need, while CKRM is still more research-ish. I find the OpenVZ code much clearer, cleaner and complete at the moment, although also much more conservative in its approach to solving problems”.
That’s right — CKRM is a complex framework for doing resource management, providing an interface to plug specific resource controllers. Framework is here, but there are not too many controllers available (and CKRM is here for a few years already). User beancounters, on the other hand, just do what they were designed for — i. e. to limit a container within its boundaries, not letting it to abuse some kernel resources and thus make troubles for other containers.
But while I was having fun, our guys did a great job posting sets of User Beancounter (UBC) patches and the network namespaces patches for a review. It looks like UBC stuff caused quite a long discussion. Some valid concerns were raised (and will be addressed).
The other thing is, besides UBC, there is also CKRM (Class-based Kernel Resource Management) out there, which basically has the same (or perhaps broader) goals. As Alan Cox puts it, “[...] OpenVZ has all the controls and resource managers we need, while CKRM is still more research-ish. I find the OpenVZ code much clearer, cleaner and complete at the moment, although also much more conservative in its approach to solving problems”.
That’s right — CKRM is a complex framework for doing resource management, providing an interface to plug specific resource controllers. Framework is here, but there are not too many controllers available (and CKRM is here for a few years already). User beancounters, on the other hand, just do what they were designed for — i. e. to limit a container within its boundaries, not letting it to abuse some kernel resources and thus make troubles for other containers.


Comments
Do you still stand by your opinions above now in 2016?…