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>
This punts the awkward-to-enforce "MUST be available at the given path
inside of the rootfs" to the kernel, which will do a much better job
of enforcing that constraint than runtime code or a static validator.
It also punts most of the semantics to POSIX, which does a better job
than we'll do at specifying this. The extension is necessary because
POSIX allows argv to be empty. In the DESCRIPTION:
The argument arg0 should point to a filename that is associated with
the process being started by one of the exec functions.
And in RATIONALE:
Early proposals required that the value of argc passed to main() be
"one or greater". This was driven by the same requirement in drafts
of the ISO C standard. In fact, historical implementations have
passed a value of zero when no arguments are supplied to the caller
of the exec functions. This requirement was removed from the ISO C
standard and subsequently removed from this volume of IEEE Std
1003.1-2001 as well. The wording, in particular the use of the word
should, requires a Strictly Conforming POSIX Application to pass at
least one argument to the exec function, thus guaranteeing that argc
be one or greater when invoked by such an application. In fact,
this is good practice, since many existing applications reference
argv[0] without first checking the value of argc.
But with an empty 'args' we will have no process to call (since
process lacks an explicit 'file' analog).
I chose the 2001/2004 POSIX spec for consistency with the existing
reference (which landed in 7ac41c69, config.md: reformat into a
standard style, 2015-06-30, which did not motivate it's use of an
older standard). For 2001 vs. 2004, [1] has:
Abstract: The 2004 edition incorporates Technical Corrigendum Number
1 and Technical Corrigendum 2 addressing problems discovered since
the approval of the 2001 edition. These are mainly due to resolving
integration issues raised by the merger of the Base documents.
and the text in the linked pages uses "IEEE Std 1003.1-2001" for
internal linking.
Rob Dolin had suggested "platform-appropriate" wording [2], but it
seems like Visual Studio 2015 supports execvp [3], and providing an
explicit "platform-appropriate" wiggle seems like it's adding useless
complication.
[1]: http://pubs.opengroup.org/onlinepubs/009695399/mindex.html
[2]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-18-17.01.log.html#l-54
[3]: https://msdn.microsoft.com/en-us/library/3xw6zy53.aspx
Signed-off-by: W. Trevor King <wking@tremily.us>
The uppercase letter / digit / underscore restriction is just for
"variables used by the utilities in the Shell and Utilities volume of
IEEE Std 1003.1-2001".
Copying over some POSIX wording and then linking to POSIX didn't seem
like much gain. Just point people at POSIX and let them read about
the name=value definition, charset suggestions, etc. there.
Also link specifically to chapter 8 section 1 (instead of just chapter
8).
Rob Dolin had suggested "platform-appropriate" wording [1], but it
seems like Visual Studio 2015 supports an environment-variable array
with the same semantics [2], and providing an explicit
"platform-appropriate" wiggle seems like it's adding useless
complication.
[1]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-18-17.01.log.html#l-54
[2]: https://msdn.microsoft.com/en-us/library/431x4c1w.aspx
Signed-off-by: W. Trevor King <wking@tremily.us>
From 766abd6f (runtime.md: Require 'create' to fail if config.json
asks for the impossible, 2016-09-08, #559).
Signed-off-by: W. Trevor King <wking@tremily.us>
According to definition of [state](runtime.md#State), we should rename
`version` field in `state.go` to `ociVersion`
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
W. Trevor King
Mrunal Patel
Mrunal Patel
Ma Shimiao
Michael Crosby
Qiang Huang
zhouhao
Vincent Batts
Rob Dolin (MSFT)
Zhang Wei
Doug Davis
Daniel, Dao Quang Minh
Jonathan Boulle