In an effort to be more discoverable and self-describing change out the
term "oci" for "opencontainer". We should consider using this as the
prefix for global namespaces going forward as oc has conflicts with
existing tools and oci is the name of the initiative not the specs.
Add support for the PIDs cgroup as a cgroup resource constraint in the
Linux container specification. Since PIDs are a real resource, we need
to support the ability to limit them.
The PIDs cgroup subsystem is available in Linux 4.3+.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This adds runtime state information for oci container's so that it can
be persisted and used by external tools.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
The field is optional, but it's nice to have at least one example of
it in use. The GIDs I've chosen are currently "tty" and "disk" on
Gentoo (1 is "bin"), which may be remotely reasonable choices, but the
values we're using don't really matter without an example filesystem
to provide context.
Signed-off-by: W. Trevor King <wking@tremily.us>
These snuck in with 7232e4b1 (specs: introduce the concept of a
runtime.json, 2015-07-30, #88) and 73bf1ba8 (JSON objects are easier
to parse/manipulate, 2015-08-27, #120).
Signed-off-by: W. Trevor King <wking@tremily.us>
Don't use strings when you can use dictionaries/objects. JSON objects are trivial to parse and manipulate, unlike strings. String parsing is the #1 cause of security bugs, so if it can be trivially avoided, then why not ;)
In #opencontainers after today's meeting, here's the source for the
change from Google Hangouts to BlueJeans:
12:01 < wking> Is the BlueJeans approach going to be our standard
procedure? If so, I can file a PR updating our weekly-meeting docs
(which still talk about YouTube and Google Hangouts)
12:03 < mrunalp> wking: Yeah, I think so.
12:04 < wking> ok. And it's just going to "push the BlueJeans link to
IRC and the list before the meeting"? Or does BlueJeans have stable
channel URLs or similar?
12:05 < mrunalp> wking: The URL that we used today is stable.
Signed-off-by: W. Trevor King <wking@tremily.us>
I touched these paragraphs while removing trailing whitespace in the
previous commit. Since I was touching them in this branch, it seemed
better to rewrap them using the "Markdown style" suggestions in the
README.
I also added a missing period after the namespaces(7) link.
Signed-off-by: W. Trevor King <wking@tremily.us>
The fact that these are Linux-specific entities should be obvious from
the context (this whole file is only about Linux-specific entities).
Signed-off-by: W. Trevor King <wking@tremily.us>
This fixes a copy/paste issue with 7232e4b1 (specs: introduce the
concept of a runtime.json, 2015-07-30, #88).
Signed-off-by: W. Trevor King <wking@tremily.us>
Based on our discussion in-person yesterday it seems necessary to
separate the concept of runtime configuration from application
configuration. There are a few motivators:
- To support runtime updates of things like cgroups, rlimits, etc we
should separate things that are inherently runtime specific from
things that are static to the application running in the container.
- To support the goal of being able to move a bundle between hosts we
should make it clear what parts of the spec are and are not portable
between hosts so that upon landing on a new host the non-portable
options may be rewritten or removed.
- In order to attach a cryptographic identity to a bundle we must not
include details in the bundle that are host specific.