It's possible, but only part of a possible solution. Those tools still would need a (standard) place to read cgroup specific data from inside the container.
Stéphane Graber's ([1] one of the LXC maintainers) comment [2] highlights just how complex the issue is because cgroups are process based. You could potentially be in a state where "top, free, etc" has a different resource allocation than the process you are monitoring (from within the container). Although, this is most likely a configuration issue i.e. classify at the container level, rather than within a container.
Personally, I think we need container aware tools baked in from the start, rather then a fork of existing ones. I guess this is where CoreOS [3] come into play. Since CoreOS is a dedicated distribution geared towards containers. I guess the idea being, that CoreOS will be fast moving, and add support for this type of thing before the mainstream distribution can (ubuntu, rhel, etc).
btw, if you do not know how cgroups work, check out my screencast on them [4].
It's not clear that CoreOS helps since it does not provide the userspace that runs inside the container. It looks like most people are building Docker images based on Ubuntu or busybox.
Yeah, you are totally right! I did not think that through enough. It is all dependent upon the tools inside the container. Should be interesting to see how this one plays out.
This issue (and many other resource measurement issues) are solved in OpenVZ but not yet in lxc. In supplying the user a whole virtual image, they are able to shortcut many of the things that don't make sense if you are only sand boxing a single process.
If you are managing a single process then you shouldn't expect to be able to sideline anything in successfully. If you do want to do that, then the single process model isn't the one you ought to use.
I think it's reasonable for lxc to say that an exiting model doesn't fit but it feels very wasteful to throw away a whole raft of user land stuff.
9 comments
[ 3.5 ms ] story [ 30.7 ms ] threadI think the key is just this bit & wanting to develop standards in the Linux container community.
Personally, I think we need container aware tools baked in from the start, rather then a fork of existing ones. I guess this is where CoreOS [3] come into play. Since CoreOS is a dedicated distribution geared towards containers. I guess the idea being, that CoreOS will be fast moving, and add support for this type of thing before the mainstream distribution can (ubuntu, rhel, etc).
btw, if you do not know how cgroups work, check out my screencast on them [4].
[1] https://linuxcontainers.org/
[2] http://fabiokung.com/2014/03/13/memory-inside-linux-containe...
[3] https://coreos.com/
[4] http://sysadmincasts.com/episodes/14-introduction-to-linux-c...
If you are managing a single process then you shouldn't expect to be able to sideline anything in successfully. If you do want to do that, then the single process model isn't the one you ought to use.
I think it's reasonable for lxc to say that an exiting model doesn't fit but it feels very wasteful to throw away a whole raft of user land stuff.