The cgroup namespace is a new kernel feature available in 4.6+ that
allows a container to isolate its cgroup hierarchy. This currently only
allows for hiding information from /proc/self/cgroup, and mounting
cgroupfs as an unprivileged user. In the future, this namespace may
allow for subtree management by a container.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This has been stale since cb2da543 (config: Single, unified config
file, 2015-12-28, #284), when we dropped the attempt to distinguish
between platform-independent and platform-dependent configuration.
Signed-off-by: W. Trevor King <wking@tremily.us>
Both fields are optional, so you could conceivably have neither.
However, in most cases folks will populate the one corresponding to
their platform. The one that *doesn't* match their platform must not
show up, in order to avoid violating the:
This should only be set if **`platform.os`** is ...
phrasing.
Signed-off-by: W. Trevor King <wking@tremily.us>
It's an optional setting, and this change will fix the wordy:
$ ocitools generate --template <(echo '{}')
$ grep readonly config.json
"readonly": false,
Instead, config.json will not contain a 'readonly' entry at all.
Signed-off-by: W. Trevor King <wking@tremily.us>
It's an optional setting, and this change will fix the wordy:
$ ocitools generate --template <(echo '{}')
$ grep terminal config.json
"terminal": false,
Instead, config.json will not contain a 'terminal' entry at all.
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>
Fixes#320
This adds the maskedPaths and readonlyPaths fields to the spec so that
proper masking and setting of files in /proc can be configured.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
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>
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>
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 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>
Vincent Batts
Aleksa Sarai
Doug Davis
Michael Holzheu
W. Trevor King
Qiang Huang
Amit Saha
Abhijeeth Nuthan
Mrunal Patel
Michael Crosby
Mrunal Patel
liangchenye
Julian Friedman