The language from 15dee2e0 (runtime: Add prestart/poststop hooks,
2015-08-03, #34) landed well before we had glossary entries for the
runtime and container namespaces (from 5dad1255, config-linux: Specify
host mount namespace for namespace paths, 2015-12-18, #275). Now that
we do have language to cover that concept, it's better to explicitly
say that hooks run in the runtime namespace instead of leaving it to
the reader to extrapolate from the filesystem requirement.
With the new namespace wording, the "host's filesystem" wording is
somewhat redundant. I've left it in though, because I think it helps
to have a more gradual transition from hook paths to namespaces.
Signed-off-by: W. Trevor King <wking@tremily.us>
* specs-go/config: Make Spec.Mounts omitempty
Otherwise:
$ ocitools generate --mount-cgroups=no --template <(echo {})
$ grep mounts config.json
"mounts": null,
The language in config.md#Mounts is:
> You can add array of mount points...
which I think means 'MAY'.
Signed-off-by: W. Trevor King <wking@tremily.us>
* config: Use 'MAY' (RFC 2119) for mounts
Signed-off-by: W. Trevor King <wking@tremily.us>
To match where they're defined in the JSON Schema [1]. The old
location is from d4e7326d (config: JSON examples, 2016-04-06, #370),
and seems to have been accidental.
[1]: 0982071b28/schema/schema-linux.json (L21-L48)
Signed-off-by: W. Trevor King <wking@tremily.us>
So that runtimes don't lock up forever waiting on a hook to return I
added a timeout field. This allows the author to specify the timeout in
seconds that they want the hook to run before aborting the hook and
container execution.
I think the hook is the proper place to specify a timeouot like this
because any type of overall timeout in the runtime will probably not
work for all hooks and will not be flexable enough.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Also:
* Update the link to Go bindings after 7bf06d5 (source and schema:
differentiate with examples, 2015-12-18, #276).
* Add a reference to the JSON Schema after cdcabde (schema: JSON
Schema and validator for `config.json`, 2016-01-19, #313).
It's pretty clear that the Go bindings cannot be canonical on their
own, because they do not define limits (e.g. the 0 through 512 range
for FileMode). The JSON Schema is closer, but still does not cover
everything (e.g. "a directory must exist at root.path"). Both the Go
bindings and the JSON Schema could grow to cover the full spec by
adding that sort of thing to comments and descriptions, but that's not
how things seem to be working now.
Signed-off-by: W. Trevor King <wking@tremily.us>
The standard is on the JSON schema (not yet IETF spec JSON-schema), such
that it is not implemenations specific. Thus far, the reference has been
in how golang source renders the JSON documents.
Having the JSON source and the markdown documents in sync has been an
ongoing step to keep in sync.
Separating these two allows the golang source to continue being _a_
reference, but the JSON schema in the documentation to be _the_
reference.
As validation tooling is refined, then it will facilitate ensuring
the available golang source conforms to the reference JSON.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
This moves process specific settings like caps, apparmor, and selinux
process label onto the process structure to allow the same settings to
be changed at exec time.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
After thorough discussion, even though a reasonable default is "/", for
platform independence, leave this up to the bundle author.
Also, by this variable being present it makes things explicit for the
runtime.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
The UTS namespace is for hostnames and NIS domain names [1]. Without
a new namespace, the hostname entry would clobber the host
environment's hostname.
Clobbering the host's hostname or a joined-namespace's hostname might
be acceptable for folks who trust their bundles, but it's not allowed
by the "error out if the config specifies anything else related to
that namespace" language that landed in 02b456e9 (Clarify behavior
around namespaces paths, 2015-09-08, #158).
[1]: http://man7.org/linux/man-pages/man7/namespaces.7.html
Signed-off-by: W. Trevor King <wking@tremily.us>
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>
If we don't specify this, some bundle-authors or runtime-implementers
might expect the runtime to intelligently order mounts to get the
"right" order [1]. But that's not possible because:
$ mkdir -p a/b/c d/e/f h
# mount --bind a/b h
# mount --bind d a/b
$ tree --charset=ascii h
h
`-- c
But in the other order:
# umount a/b
# umount h
# mount --bind d a/b
# mount --bind a/b h
$ tree --charset=ascii h
h
`-- e
`-- f
So there's no "right" order. Allowing the bundle-author to specify
their intended order is both easy to implement and unambiguous.
[1]: https://github.com/opencontainers/specs/pull/136#issuecomment-137275876
Suggested-by: Lai Jiangshan <jiangshanlai@gmail.com>
Signed-off-by: W. Trevor King <wking@tremily.us>
Vincent Batts
Abhijeeth Nuthan
Michael Crosby
W. Trevor King
Amit Saha
Mrunal Patel
Rob Dolin (MSFT)
Mrunal Patel
Kenfe-Mickael Laventure
liangchenye
Julian Friedman
Vishnu kannan
Qiang Huang
Doug Davis
Lai Jiangshan
Will Pragnell
Alexander Morozov