Catch the Markdown spec up with the JSON Schema change in 09274372
(schema: Drop pointers and nulls, 2017-01-18, #662). The Markdown is
canonical, so we could restore the explicit-null handling to the JSON
Schema instead, but the maintainers feel (and I agree) that there's no
point in explicitly allowing a null value when callers can simply
leave the property unset [1].
[1]: https://github.com/opencontainers/runtime-spec/pull/555#issuecomment-272020515
Signed-off-by: W. Trevor King <wking@tremily.us>
Any runtime which violated that constraint would necessarily violate
some more specific constraint on a 'resources' setting.
This also removes a non-spec-requirement "required" to avoid any
confusion with the spec-requirement REQUIRED [1].
[1]: https://github.com/opencontainers/runtime-spec/pull/729#issue-214550260
Signed-off-by: W. Trevor King <wking@tremily.us>
Since f9dc90b0 (make link usage consistent across the specification,
2017-02-09, #687), the official style is to only use reference-style
links for external links. I expect the remaining three entries just
slipped through. This commit adjusts everything found with:
$ git grep ']: [a-z]' | grep -v http
It also fixes the underscore -> hyphen in the
glossary.md#container-namespace target and updates the capabilities
location to catch up with 5a8a779f (Move process specific settings to
process, 2016-03-02, #329).
Signed-off-by: W. Trevor King <wking@tremily.us>
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>
So we can compliance-test runtimes for these settings.
Also remove the tutorial, since the kernel docs should provide
sufficient documentation on that front. The kernel can be patched if
they do not, and we do not include tutorials for other config-linux
settings in this spec.
The updated example was recommended by Xiaochen to compensate for the
removed inline tutorial [1].
[1]: https://github.com/opencontainers/runtime-spec/pull/787#discussion_r114254422
Signed-off-by: W. Trevor King <wking@tremily.us>
The previous wording hinted at, but did not require, this setting to
be implemented via oom_score_adj. With the new wording, when proc is
mounted at /proc, the container process can check this value by
looking at /proc/self/oom_score_adj.
Signed-off-by: W. Trevor King <wking@tremily.us>
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>
This was broken by f9dc90b0 (make link usage consistent across the
specification, 2017-02-09, #687), which updated the link label, but
not this link. Now that the link label matches the link text, we can
use the implicit link name shortcut [1].
[1]: https://daringfireball.net/projects/markdown/syntax#link
Signed-off-by: W. Trevor King <wking@tremily.us>
I expect the (undocumented) intention here is to iterate through
'names' and call seccomp_rule_add(3) or similar for each name. In
that case, an empty 'names' makes the whole syscall entry a no-op, and
with this commit we can warn users who are validating such configs.
If, on the other hand, we were comfortable with no-op syscall entries,
we'd want to make 'names' OPTIONAL.
Warning folks who accidentally empty (or don't set) 'names' seems more
useful to me, and doesn't restrict the useful config space, so that's
what I've gone with in this commit.
minItems is documented in [1], and there is an example of its use in
[2]:
"options": {
"type": "array",
"minItems": 1,
"items": { "type": "string" },
"uniqueItems": true
},
[1]: https://tools.ietf.org/html/draft-wright-json-schema-validation-00#section-5.11
[2]: http://json-schema.org/example2.html
Signed-off-by: W. Trevor King <wking@tremily.us>
We have a few different element types in our arrays, so it's useful to
clarify the element type for the property being specified. Before
this commit:
$ sed -n 's|.*\*\*`\([^`]*\)`\*\*[^(]*(\([^,]*\),.*|\2|p' *.md | sort | uniq -c | grep array
7 array
1 array of ints
8 array of objects
13 array of strings
All of the bare 'array' instances turned out to be arrays of objects.
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>
I think runtime should generate an error, if devices has
duplicated device path.
Because we don't know which one is really needed.
Signed-off-by: Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
This restriction originally landed via 02b456e9 (Clarify behavior
around namespaces paths, 2015-09-08, #158). The hostname case landed
via 66a0543e (config: Require a new UTS namespace for config.json's
hostname, 2015-10-05, #214) citing the namespace restriction. The
restriciton extended to runtime namespaces in 01c2d55f (config-linux:
Extend no-tweak requirement to runtime namespaces, 2016-08-24, #538).
There was a proposal in-flight to get config-wide consistency around
the no-tweaking concept [1].
In today's meeting, the maintainer consensus was to strike the
no-tweaking restriction [2], which is what I've done here. I've
removed the ROADMAP entry because this gives folks a way to adjust
existing containers (launch a new container which joins and tweaks the
original).
The hostname entry still mentions the UTS namespace to provide a guard
against accidental foot-gunning. There was no no-tweaking language
for properties related to other namespaces (e.g. 'mounts').
Maybe the other namespaces have more obvious names.
[1]: https://github.com/opencontainers/runtime-spec/pull/540
[2]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2017/opencontainers.2017-01-11-22.04.log.html#l-117
Signed-off-by: W. Trevor King <wking@tremily.us>
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>
W. Trevor King
Michael Crosby
Mrunal Patel
Tianon Gravi
v1.0.0.batts
Qiang Huang
zhouhao
Xiaochen Shen
Ma Shimiao
Jesse Butler
Mrunal Patel
grantseltzer
Daniel Dao
Rob Dolin (MSFT)
Doug Davis