The only discussion related to this is in [1,2], where the
relationship between oomScoreAdj and disableOOMKiller is raised. But
since 429f936 (Adding cgroups path to the Spec, 2015-09-02, #137)
resources has been tied to cgroups, and oomScoreAdj is not about
cgroups. For example, we currently have (in config-linux.md):
You can configure a container's cgroups via the resources field of
the Linux configuration.
I suggested we move the property from linux.resources.oomScoreAdj to
linux.oomScoreAdj so config authors and runtimes don't have to worry
about what cgroupsPath means if the only entry in resources is
oomScoreAdj. Michael responded with [4]:
If anything it should probably go on the process
So that's what this commit does.
I've gone with the four-space indents here to keep Pandoc happy (see
7795661 (runtime.md: Fix sub-bullet indentation, 2016-06-08, #495),
but have left the existing entries in this list unchanged to reduce
churn.
[1]: https://github.com/opencontainers/runtime-spec/pull/236
[2]: https://github.com/opencontainers/runtime-spec/pull/292
[3]: https://github.com/opencontainers/runtime-spec/pull/137
[4]: https://github.com/opencontainers/runtime-spec/issues/782#issuecomment-299990075
Signed-off-by: W. Trevor King <wking@tremily.us>
Avoid injecting:
"consoleSize":{"height":0,"width":0}
when serializing with Go's stock JSON serializer. Using a pointer for
this optional struct property works around [1].
[1]: https://github.com/golang/go/issues/11939
Signed-off-by: W. Trevor King <wking@tremily.us>
In order to increase the granularity of CPU resource control, change
the CPU Percent (0-100) resource setting to CPU Maximum (0-10000)
Signed-off-by: Darren Stahl <darst@microsoft.com>
Before this commit, linux.seccomp.sycalls was required, but we didn't
require an entry in the array. That means '"syscalls": []' would be
technically valid, and I'm pretty sure that's not what we want.
If it makes sense to have a seccomp property that does not need
syscalls entries, then syscalls should be optional (which is what this
commit is doing).
If it does not makes sense to have an empty/unset syscalls then it
should be required and have a minimum length of one.
Before 652323c (improve seccomp format to be more expressive,
2017-01-13, #657), syscalls was omitempty (and therefore more
optional-feeling, although there was no real Markdown spec for seccomp
before 3ca5c6c, config-linux.md: fix seccomp, 2017-03-02, #706, so
it's hard to know). This commit has gone with OPTIONAL, because a
seccomp config which only sets defaultAction seems potentially valid.
The SCMP_ACT_KILL example is prompted by:
On Tue, Apr 25, 2017 at 01:32:26PM -0700, David Lyle wrote [1]:
> Technically, OPTIONAL is the right value, but unless you specify the
> default action for seccomp to be SCMP_ACT_ALLOW the result will be
> an error at run time.
>
> I would suggest an additional clarification to this fact in
> config-linux.md would be very helpful if marking syscall as
> OPTIONAL.
I've phrased the example more conservatively, because I'm not sure
that SCMP_ACT_ALLOW is the only possible value to avoid an error. For
example, perhaps a SCMP_ACT_TRACE default with an empty syscalls array
would not die on the first syscall. The point of the example is to
remind config authors that without a useful syscalls array, the
default value is very important ;).
Also add the previously-missing 'required' property to the seccomp
JSON Schema entry.
[1]: https://github.com/opencontainers/runtime-spec/pull/768#issuecomment-297156102
Signed-off-by: W. Trevor King <wking@tremily.us>
It used to have this, but the omitempty was dropped in 652323cd
(improve seccomp format to be more expressive, 2017-01-13, #657).
However, the docs that landed in 3ca5c6c5 (config-linux.md: fix
seccomp, 2017-03-02, #706) list the property as optional, and if it is
optional, we can leave it unset instead of serializing an empty array.
Signed-off-by: W. Trevor King <wking@tremily.us>
Add support for Intel Resource Director Technology (RDT) / Cache Allocation
Technology (CAT). Add L3 cache resource constraints in Linux-specific
configuration.
This is the prerequisite of this runc proposal:
https://github.com/opencontainers/runc/issues/433
For more information about Intel RDT/CAT, please refer to:
https://github.com/opencontainers/runc/issues/433
Signed-off-by: Xiaochen Shen <xiaochen.shen@intel.com>
This partially revert #648 , after a second thought, I think we
should use specs value the same as kernel API input, see:
https://github.com/opencontainers/runtime-spec/issues/692#issuecomment-281889852
For memory and hugetlb limits *.limit_in_bytes, cgroup APIs take the values
as string, but the parsed values are unsigned long, see:
https://github.com/torvalds/linux/blob/v4.10/mm/page_counter.c#L175-L193
For `cpu.cfs_quota_us` and `cpu.rt_runtime_us`, cgroup APIs take the input
value as signed long long, while `cpu.cfs_period_us` and `cpu.rt_periof_us`
take the input value as unsigned long long.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
These are optional on multiple platforms and should be left up to the
runtime/host system for validation.
Closes#470
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Carry #499
For these values, cgroup kernal APIs accept -1 to set
them as unlimited, as docker and runc all support
update resources, we should not set drawbacks in spec.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
We dropped these in 47740802 (specs-go/config: Drop "this field is
platform dependent", 2016-09-14, #568) but f9e48e00 (Windows: User
struct changes, 2016-09-14, #565) was developed in parallel and
brought in a new one.
Signed-off-by: W. Trevor King <wking@tremily.us>
These comments first landed in 820131db (*: flatten platform dependent
source, 2016-03-08, #310). But you can tell they're platform
dependent by the platform:"..." tags. The Go comment doesn't add
any additional information.
Signed-off-by: W. Trevor King <wking@tremily.us>
And mark it omitempty to avoid:
$ ocitools generate --template <(echo '{"linux": {"resources": {}}}') | jq .linux
{
"resources": {
"devices": null
}
}
Signed-off-by: W. Trevor King <wking@tremily.us>
I've replaced the old OPTIONAL with our usual:
(<type>, <optional|required>)
to get the property name first, since that translates more directly
into a Go comment that godoc will like.
The new Go comment is much shorter, dropping "unstructured" (because
the Markdown says "structured or unstructured") and "set by external
tools..." (because *everything* in the configuration JSON is set by
external-to-the-runtime tools).
Signed-off-by: W. Trevor King <wking@tremily.us>
The new wording isn't particularly close to either of the old
wordings, but it reads more clearly to me. I've also added our usual:
(<type>, <required|optional>)
to the Markdown so folks can see that this is an optional object
(although see [1] for a more complete version).
[1]: https://github.com/opencontainers/runtime-spec/pull/427
Subject: config: Explicitly list 'hooks' as optional
Signed-off-by: W. Trevor King <wking@tremily.us>
Michael Crosby
Ma Shimiao
Daniel, Dao Quang Minh
W. Trevor King
Darren Stahl
zhouhao
Tianon Gravi
Qiang Huang
Mrunal Patel
Xiaochen Shen
grantseltzer
Mrunal Patel
Vincent Batts
John Howard