Support for flat cgroups, and use more portable mountpoint #4

Merged
merged 3 commits into from Feb 25, 2014

Conversation

Projects
None yet
2 participants
@vito
Contributor

vito commented Feb 24, 2014

This makes Garden more portable. The host can now have either a flat cgroup mount or per-subsystem cgroup mounts. Also the intermediate mount point is named more explicitly so as to not conflict with other containerization stuff that uses "mnt" (like Docker).

vito added some commits Feb 16, 2014

detect flat cgroup mount, mount cgroup accordingly
If an existing cgroup mount is mounted flat, all other cgroup mounts have to
be flat as well. Similarly, if there are existing mounts for individual
subsystems, other mounts have to be done the same. So, detect if there's an
existing flat mount, and mount ours flat as well, and just bind-mount each
subsystem.
use more specific intermediate host mount point
mnt/ is very generic and happens to match other containerization systems'
(say, Docker/LXC) mount points, so running Garden in them is tricky.

so, mount to tmp/warden-host instead. this mount point only exists for a brief
period of time during container creation (after pivot_root and before the
daemon starts), so it makes sense to be as portable as possible.
@glyn

This comment has been minimized.

Show comment Hide comment
@glyn

glyn Feb 24, 2014

Member

Not sure about this change. Why hard-code the subsystem names here (as this seems like a maintenance issue)? What happens in the "flat mount" case (which I presume means that all the subsystems are mounted using a single mount command) - is there some alternative path which avoids the code here?

Not sure about this change. Why hard-code the subsystem names here (as this seems like a maintenance issue)? What happens in the "flat mount" case (which I presume means that all the subsystems are mounted using a single mount command) - is there some alternative path which avoids the code here?

This comment has been minimized.

Show comment Hide comment
@vito

vito Feb 24, 2014

Contributor

It's just the cgroup subsystems that we use in the backend. It's not something that's configurable, and given that this code is only relevant when shipped with the backend that's using it, it shouldn't be a maintenance issue.

In the "flat mount" case, when Garden starts up (see setup.sh) each subsystem is created under the tmp/warden/cgroup mount, as a simple bind-mount that points to the flat mount point at tmp/warden/cgroup. This means all code that assumes distinct subsystem mounts doesn't have to change.

Contributor

vito replied Feb 24, 2014

It's just the cgroup subsystems that we use in the backend. It's not something that's configurable, and given that this code is only relevant when shipped with the backend that's using it, it shouldn't be a maintenance issue.

In the "flat mount" case, when Garden starts up (see setup.sh) each subsystem is created under the tmp/warden/cgroup mount, as a simple bind-mount that points to the flat mount point at tmp/warden/cgroup. This means all code that assumes distinct subsystem mounts doesn't have to change.

This comment has been minimized.

Show comment Hide comment
@glyn

glyn Feb 24, 2014

Member
Member

glyn replied Feb 24, 2014

This comment has been minimized.

Show comment Hide comment
@vito

vito Feb 24, 2014

Contributor
Contributor

vito replied Feb 24, 2014

This comment has been minimized.

Show comment Hide comment
@glyn

glyn Feb 24, 2014

Member
Member

glyn replied Feb 24, 2014

@glyn

This comment has been minimized.

Show comment Hide comment
@glyn

glyn Feb 24, 2014

Member

What does "an existing cgroup mount is mounted flat" mean?

Member

glyn commented on d66f6aa Feb 24, 2014

What does "an existing cgroup mount is mounted flat" mean?

This comment has been minimized.

Show comment Hide comment
@vito

vito Feb 24, 2014

Contributor

@glyn

In any given host system there are two ways an existing cgroup mount may have been mounted: as a single flat cgroup mount point with all pseudo files under it, or as several distinct mount points for each subsystem. Warden and garden would set up the latter style, but that fails if the host already has an existing flat mount point. Which is pretty annoying, but documented.

This primarily affects the use case of Garden in Docker for CI/testing with Drone. boot2docker mounts flat, while most Ubuntu systems have separate mount points per subsystem. I want our workflow to be "start boot2docker -> run tests"; currently it's more complicated.

Contributor

vito replied Feb 24, 2014

@glyn

In any given host system there are two ways an existing cgroup mount may have been mounted: as a single flat cgroup mount point with all pseudo files under it, or as several distinct mount points for each subsystem. Warden and garden would set up the latter style, but that fails if the host already has an existing flat mount point. Which is pretty annoying, but documented.

This primarily affects the use case of Garden in Docker for CI/testing with Drone. boot2docker mounts flat, while most Ubuntu systems have separate mount points per subsystem. I want our workflow to be "start boot2docker -> run tests"; currently it's more complicated.

fix accidental comment-out of wshd log redirect
Signed-off-by: Abhijit Hiremagalur <abhi@pivotallabs.com>

vito added a commit that referenced this pull request Feb 25, 2014

Merge pull request #4 from pivotal-cf-experimental/flat-cgroup
Support for flat cgroups, and use more portable mountpoint

@vito vito merged commit 75b2e9b into master Feb 25, 2014

1 check passed

default The Travis CI build passed
Details

@vito vito deleted the flat-cgroup branch Jul 17, 2014

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