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>
Avoid trouble with situations like:
# mount --bind /mnt/test /mnt/test
# mount --make-rprivate /mnt/test
# touch /mnt/test/mnt /mnt/test/user
# mount --bind /proc/123/ns/mnt /mnt/test/mnt
# mount --bind /proc/123/ns/user /mnt/test/user
# nsenter --mount=/proc/123/ns/mnt --user /proc/123/ns/user sh
which uses the required private mount for binding mount namespace
references [1,2,3]. We want to avoid:
1. Runtime opens /mnt/test/mnt as fd 3.
2. Runtime joins the mount namespace referenced by fd 3.
3. Runtime fails to open /mnt/test/user, because /mnt/test is not
visible in the current mount namespace.
and instead get runtime authors to setup flows like:
1. Runtime opens /mnt/test/mnt as fd 3.
2. Runtime opens /mnt/test/user as fd 4.
3. Runtime joins the mount namespace referenced by fd 3.
4. Runtime joins the user namespace referenced by fd 4.
This also applies to new namespace creation. We want to avoid:
1. Runtime clones a container process with a new mount namespace.
2c. Container process fails to open /mnt/test/user, because /mnt/test
is not visible in the current mount namespace.
in favor of something like:
1. Runtime opens /mnt/test/user as fd 3.
2. Runtime clones a container process with a new mount namespace.
3h. Host process closes unneeded fd 3.
3c. Container process joins the user namespace referenced by fd 3.
I also define runtime and container namespaces, so we have consistent
terminology. I prefer:
* host namespace: a namespace you are in when you invoke the runtime
* host process: the runtime process invoked by the user
* container process: the process created by a clone call in the host
process which will eventually execute the user-configured process.
Both the host and container processes are running runtime code
(although the container process eventually transitions to
user-configured code), so I find "runtime process", "runtime
namespace", etc. to be imprecise. However, the maintainer consensus
is for "runtime namespace" [4,5], so that's what we're going with
here.
[1]: http://karelzak.blogspot.com/2015/04/persistent-namespaces.html
[2]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4ce5d2b1a8fde84c0eebe70652cf28b9beda6b4e
[3]: http://mid.gmane.org/87haeahkzc.fsf@xmission.com
[4]: https://github.com/opencontainers/specs/pull/275#discussion_r48057211
[5]: https://github.com/opencontainers/specs/pull/275#discussion_r48324264
Signed-off-by: W. Trevor King <wking@tremily.us>
By using ffjson for json encoding we can reduce the time for encoding
and decoding.
Without:
BenchmarkMarsalSpec-4 100000 18276 ns/op
BenchmarkUnmarshal-4 30000 55115 ns/op
With:
BenchmarkMarsalSpec-4 100000 13649 ns/op
BenchmarkUnmarshal-4 50000 24747 ns/op
This is a reduces time about 25% on marshal and 50% on unmarshal.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
This adds basic benchmark tests for the performace of marshaling and
unmarshaling the spec into json. These tests are helpful to optimize
the performace because the main way the spec is consumed is via json.
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>
Through 0bcb7119 (Merge pull request #341 2016-03-10).
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
This introduces verbiage of fields that may occur in json (technically
optional), but is required on certain platforms (e.g. Linux).
The JSON document will look the same as it presently does, but now the
reference source compiles regardless of platform.
Not adding a "name" string to the user sturct, as that is not a
requirement yet.
In the event a windows runtime shows up, I could imagine an `sid` on the
user struct, but we'll get to that when it happens.
Closes https://github.com/opencontainers/specs/pull/135
Related to https://github.com/opencontainers/specs/issues/166
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
The label changed in 5a8a779f (Move process specific settings to
process, 2016-03-02, #329) and 7bf06d53 (source and schema:
differentiate with examples, 2015-12-18, #276) missed this instance
when rebasing around #329.
Signed-off-by: W. Trevor King <wking@tremily.us>
The only reference was removed in 15a43acd (ReadMe: Replace BlueJeans
with UberConference, 2016-02-24, #326).
Signed-off-by: W. Trevor King <wking@tremily.us>
Conforming to https://tools.ietf.org/html/draft-zyp-json-schema-03
and http://json-schema.org/latest/json-schema-core.html
* Utilizes a number of JSON schema features, including 'pattern'
* Defined primitives, like integers, that we'll use
* Split out definitions for primitives and platform-specific
* Provide a Makefile for:
- "fmt" target for *.json
- "validate" target for building the validation tool
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
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>
Update the Table of Contents section of the ReadMe.md to match the order
of the merged MarkDown files in the printable HTML and PDF outputs
Signed-off-by: Rob Dolin <RobDolin@microsoft.com>
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>
Antonio Murdaca
Giuseppe Scrivano
Mrunal Patel
Michael Crosby
Qiang Huang
Vincent Batts
W. Trevor King
liangchenye
Julian Friedman
Rob Dolin (MSFT)
Vishnu kannan
Mrunal Patel