The former definition was join "/" when `cgroupsPath` is absent, it's
not clear whether to join the root cgroup or create a sub cgroup under "/".
Join root cgroup would be a bad idea cause that's not what a container
should do. And craete a sub cgroup would be missing definition about what
the cgroup name should that be.
So I think we should leave this to implementations what the default
cgroup path should be.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
- add information to cgroup resources controllers with examples
- add pids cgroup information and example
- reflect kernel types
Signed-off-by: Antonio Murdaca <runcom@linux.com>
we have both styles in the *.md, we should use only one of the styles.
**`name`** is much prettier than **name** in the result,
so we use **`name`**
Signed-off-by: Lai Jiangshan <jiangshanlai@gmail.com>
By default, Seccomp filters will only permit syscalls to be made using the
native architecture of the kernel. This is fine for most use cases, but breaks
others (such as running 32-bit code in a container on a host with a 64-bit
kernel). This patch adds a field to specify additional architectures which may
make syscalls.
Signed-off-by: Matthew Heon <mheon@redhat.com>
`WeightDevice`, `ThrottleReadBpsDevice`, `ThrottleWriteBpsDevice`,
`ThrottleReadIOpsDevice`, `ThrottleWriteIOpsDevice` are now slices to
well defined structs to allow setting multiple devices in their respective
blkio file. By using a string to represents those values it wasn't possible
to set correct values when multiple devices were passed in the config
(either newline separated or comma separated).
Signed-off-by: Antonio Murdaca <runcom@linux.com>
There are two RootfsPropagation fields, one is Linux.RootfsPropagation,
the other one is LinuxRuntime.RootfsPropagation. They are duplicated,
one of them should be removed.
The RootfsPropagation is definitely a runtime specific configuration,
so we remove the one of Linux.RootfsPropagation.
And the description of it is moved from config-linux.md to
runtime-config-linux.md.
Signed-off-by: Lai Jiangshan <jiangshanlai@gmail.com>
Add support for the PIDs cgroup as a cgroup resource constraint in the
Linux container specification. Since PIDs are a real resource, we need
to support the ability to limit them.
The PIDs cgroup subsystem is available in Linux 4.3+.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
These snuck in with 7232e4b1 (specs: introduce the concept of a
runtime.json, 2015-07-30, #88) and 73bf1ba8 (JSON objects are easier
to parse/manipulate, 2015-08-27, #120).
Signed-off-by: W. Trevor King <wking@tremily.us>
I touched these paragraphs while removing trailing whitespace in the
previous commit. Since I was touching them in this branch, it seemed
better to rewrap them using the "Markdown style" suggestions in the
README.
I also added a missing period after the namespaces(7) link.
Signed-off-by: W. Trevor King <wking@tremily.us>
The fact that these are Linux-specific entities should be obvious from
the context (this whole file is only about Linux-specific entities).
Signed-off-by: W. Trevor King <wking@tremily.us>
This fixes a copy/paste issue with 7232e4b1 (specs: introduce the
concept of a runtime.json, 2015-07-30, #88).
Signed-off-by: W. Trevor King <wking@tremily.us>
Based on our discussion in-person yesterday it seems necessary to
separate the concept of runtime configuration from application
configuration. There are a few motivators:
- To support runtime updates of things like cgroups, rlimits, etc we
should separate things that are inherently runtime specific from
things that are static to the application running in the container.
- To support the goal of being able to move a bundle between hosts we
should make it clear what parts of the spec are and are not portable
between hosts so that upon landing on a new host the non-portable
options may be rewritten or removed.
- In order to attach a cryptographic identity to a bundle we must not
include details in the bundle that are host specific.