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

Allow cgroup creation without attaching a pid #956

Merged
merged 1 commit into from
Jul 20, 2016

Conversation

dubstack
Copy link

@dubstack dubstack commented Jul 19, 2016

I am working on introducing pod level cgroups in Kubernetes (kubernetes/kubernetes#27204). As a part I would like to use libcontainer for creating and managing cgroups in the system. I would like to just create a cgroup with no pid attached and if need be apply a pid to the cgroup later on. But currently libcontainer doesn't support cgroup creation without attaching a pid.

This would allow us to skip attaching a pid to a cgroup during creation.
cc @mrunalp @vishh @derekwaynecarr

return err
// Dont attach any pid to the cgroup if -1 is specified as a pid
if pid != -1 {
if err := ioutil.WriteFile(filepath.Join(path, "cgroup.procs"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While replacing this, maybe we should be using writeFile here instead of ioutil.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds Good.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re above, Now that I looked into it more carefully this was done to avoid import cycles.
I would suggest that we move the WriteFile method to cgroups.utils.go.

Or we can also not make any such changes and continue to use ioutil in the utils.go file.

@cyphar
Copy link
Member

cyphar commented Jul 20, 2016

Just to be clear, this is kubernetes using libcontainer as a library for its own internal management of things -- not as part of the OCI integration being worked on (which would mean making changes to the runtime specification and a few other things)?

@dubstack
Copy link
Author

Yes this is needed for Kubernete's internal implementation.

@mrunalp
Copy link
Contributor

mrunalp commented Jul 20, 2016

LGTM

Approved with PullApprove

if err := writeFile(path, CgroupProcesses, strconv.Itoa(raw.pid)); err != nil {
return "", err
// Dont attach any pid to the cgroup if -1 is specified as a pid
if raw.pid != -1 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i worry the -1 is kind of undocumented unless we have it that all writeFile calls to cgroup.procs share a common function call. a lot of this code is not unit tested, so would prefer that we at least consolidate the -1 checking into a common function like writeCgroupProc(pid int) and just keep the -1 check local to there..

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that sounds reasonable.

@dubstack
Copy link
Author

@derekwaynecarr @mrunalp @cyphar PTAL

@derekwaynecarr
Copy link
Contributor

LGTM, thanks for the update.

@crosbymichael
Copy link
Member

@cyphar write file is not complicated, we can fix it or remove it

@dubstack
Copy link
Author

Should we consider moving a bunch of "utility like" functions in apply_raw to utils.go ??

@cyphar
Copy link
Member

cyphar commented Jul 20, 2016

We should probably move writeFile (as it was originally written) into libcontainer/utils because it's legitimately useful elsewhere.

@dubstack
Copy link
Author

I will send out a PR for the same.

@dubstack
Copy link
Author

@cyphar Can you LGTM this PR as it's blocking other PR's.

I will move the writeFile to libcontainer/utils in a different PR.

@cyphar
Copy link
Member

cyphar commented Jul 20, 2016

LGTM, sure. But you still need one more maintainer to LGTM this version of the PR.

Approved with PullApprove

@dubstack
Copy link
Author

Oh, right! cc @mrunalp

@mrunalp
Copy link
Contributor

mrunalp commented Jul 20, 2016

LGTM

Approved with PullApprove

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

Successfully merging this pull request may close these issues.

6 participants