Extract cgroups utilities to own submodule.#3310
Conversation
|
@crosbymichael this is just a start there is clearly a lot more we can do to put in decent structure and naming and testing. In part I wanted to ask should this actually be resources/... then having cgroups as an implementor. |
|
I wonder if we should replace that /proc/mounts scanning with @crosbymichael's new mountinfo reading stuff. |
|
@tianon @crosbymichael it seems reasonable I'll ammend to support the needed search and update this once done. |
|
I love it :), but +1 @tianon. Can't wait to merge this! |
|
Does this now need to go under |
|
@pnasrat Yes, please move it to |
|
@pnasrat Please, can you rebase? |
|
Yeah I just need to make some changes then push - probably tomorrow. On 26 December 2013 19:24, Guillaume J. Charmes notifications@github.comwrote:
|
|
Integration tests are failing - hold off review until I ping this PR again. |
|
Logic was broken in rebasing, fixed but want to add some unit tests. |
|
@creack @crosbymichael @tianon PTAL. |
|
Tests pass locally and http://docker-ci.dotcloud.com/builders/pullrequest/builds/2247 |
|
Rebased again - @creack @crosbymichael @tianon |
|
+1 - looks reasonable to me |
cgroups/cgroups.go
Outdated
There was a problem hiding this comment.
You don't need var here for only one declaration
Use mountinfo rather than for cgroups parsing. Make helper method private and change name. Makes method naming more explicit rather than GetThisCgroup. Use upstream term subsystem rather than cgroupType.
|
@crosbymichael addressed your line comments. |
|
LGTM |
|
LGTM, ping @crosbymichael |
Extract cgroups utilities to own submodule.
Initial extraction of methods, no functionality changes or additions.