Why not default to /docker to be accurate?

okay

Should be "/docker"?

I had this draft, not really satisfied with it, but feel free to use if you think it reads better 😄

# Default cgroup parent

The `--cgroup-parent` option allows you to set the default cgroup parent
to use for containers. If this option is not set, it defaults to `/docker`.

If the cgroup has a leading forward slash (`/`), the cgroup is created
under the root cgroup, otherwise the cgroup is created under the daemon
cgroup.

Assuming the daemon is running in cgroup `daemoncgroup`,
`--cgroup-parent=/foobar` creates a cgroup in
`/sys/fs/cgroup/memory/foobar`, wheras using `--cgroup-parent=foobar`
creates the cgroup in `/sys/fs/cgroup/memory/daemoncgroup/foobar`

This setting can also be set per container, using the `--cgroup-parent`
option on `docker create` and `docker run`, and takes precedence over
the `--cgroup-parent` option on the daemon. 

@LK4D4 Is this value only valid when the native.cgroupdriver is cgroupsfs? Or does it work if that value is also systemd? I'd change the text depending on your answer.

Regarding the material, it took me a few tries to untangle it. I'm sorry I couldn't test it entirely, but I think this might be better way to phrase the section. Please review.

--->

Default cgroup parent

The cgroups (control group) feature is used to limit a container's access to the
host's resources. The --cgroup-parent option sets the default cgroup parent
for all containers. You can also set this option per container when you call
docker create or docker run commands. The subcommand value overrides the
daemon's --cgroup-parent option setting.

The Docker host stores cgroups in relation to the /sys/fs/cgroup/memory root
directory. Where the cgroup is created in relation to this root directory,
depends on whether and how you specify the --cgroup-parent option value. If
you don't specify the --cgroup-parent option, the daemon uses
/sys/fs/cgroup/memory/docker as the parent.

If you set this option, the option value can start with a leading forward slash (/)
or without one. The presence or absence of a slash determines where the cgroup
is located in the /sys/fs/cgroup/memory directory. If you specify a slash in
the value, for example --cgroup-parent=/foobar, Docker creates a
/sys/fs/cgroup/memory/foobar folder.

If you don't include the slash, Docker creates a
/sys/fs/cgroup/memory/daemoncgroup folder and places your group within it. For
example, if you specify --cgroup-parent=foobar the system creates the cgroup
in the /sys/fs/cgroup/memory/daemoncgroup/foobar directory.

It should work for systemd driver if the argument is a systemd slice.

Sent from my iPhone

On Dec 19, 2015, at 8:21 PM, moxiegirl [email protected] wrote:

In docs/reference/commandline/daemon.md:

@@ -643,4 +644,20 @@ set like this:
/usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// > /var/lib/docker-machine/docker.log 2>&1

+# Default cgroup parent
@LK4D4 Is this value only valid when the native.cgroupdriver is cgroupsfs? Or does it work if that value is also systemd?

—
Reply to this email directly or view it on GitHub.

@mrunalp can you provide me with an example of specifying the option in this way?

Something like "containers.slice"

Sent from my iPhone

On Dec 19, 2015, at 9:27 PM, moxiegirl [email protected] wrote:

In docs/reference/commandline/daemon.md:

@@ -643,4 +644,20 @@ set like this:
/usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// > /var/lib/docker-machine/docker.log 2>&1

+# Default cgroup parent
@mrunalp can you provide me with an example of specifying the option in this way?

—
Reply to this email directly or view it on GitHub.

@moxiegirl: What you have is a good start. Couple of high level comments:

1. This option is available both for "docker daemon" and "docker run". We can add help at the daemon level and reference it from the run subcommand (or vice versa).
2. Given that the behaviour is different depending on native.cgroupdriver choice, it's better to split this section by the same (native.cgroupdriver)

Proceeding to review what you have for cgroupfs:

• Avoid having references to the cgroup memory subsystem alone. For ex, /sys/fs/cgroup/memory. All cgroup subsystems listed in /proc/subsystems will have the newly created cgroup.
• Reference to daemoncgroup sounds incorrect. Can you point the source of this info?

For cgroup-parent option on systemd cgroups, you can use the following content:

When cgroups are managed by systemd (using --exec-opt native.cgroupdriver=systemd), containers are created by default under system.slice. Custom systemd slices can be used to group containers and control resource limits on them. Custom slices can be created by adding slice units in /etc/systemd/system. For example, create a limits.slice (ref. http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html)

Run containers in limits.slice using --cgroup-parent:
docker run -it --cgroup-parent=limits.slice busybox sh
docker run -it --cgroup-parent=limits.slice ubuntu bash

Using systemd-cgls, observe that both containers are created under limits.slice. Note that limits.slice is in the same hierarchical level as system.slice.

├─system.slice
│ ├─thermald.service
│ │ └─654 /usr/sbin/thermald --no-daemon --dbus-enable
│ ├─dbus.service
│ │ ├─ 728
...

├─limits.slice
│ ├─docker-d8119d36eea49874ddfa8e8f83c3aa72730b3e57ae6cb43bfd4d299154a24a5c.scope
│ │ └─2330 bash
│ └─docker-d4f053a9bbefb30831ead236ed9716522f3eb2cc50d3443f30ea41f4da766939.scope
│ └─2284 sh

For each container, a docker-containerID.scope is created under /sys/fs/cgroup/subsystem/<cgroup-parent