specs: introduce the concept of a runtime.json #88

philips · 2015-07-30T19:43:26Z

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.

This is a WIP to generate discussion.

wking · 2015-07-30T22:48:34Z

bundle.md

+This includes two configuration files `config.json` and `runtime.json`, and a rootfs directory.
+The `config.json` file contains settings that are host independent and application specific such as security permissions, environment variables and arguments.
+The `runtime.json` file contains settings that are host specific such as memory limits, local device access and mount points.
+The goal is that the bundle can be moved as a unit to another machine and run the same container if runtime.json is removed or reconfigured.


You're missing backticks around runtime.json here. And I'm having trouble parsing this sentence as a whole, but I'm not sure how to rephrase it to make it read more clearly.

Parsing this sentence is difficult because we don't have solid nouns in the spec yet, I think.

In the appc spec the thing that is contained and executed is called "the app". So, I could rephrase it this way:

"The goal is that the bundle can be moved, as a unit, to another machine and the app is executed in a similar manner on the new host if runtime.json is removed or reconfigured."

On Tue, Aug 04, 2015 at 09:55:12PM -0700, Brandon Philips wrote:

In the appc spec the thing that is contained and executed is called "the app".

So you have:

bundles, which get written ahead of time, distributed, and used to
seed the runtime

containers, which are the environment setup for the application
(namespaces, cgroups, mounts, …)

applications, which are the process trees launched inside the
containers

That seems reasonable to me. Should I PR a glossary?

"The goal is that the bundle can be moved, as a unit, to another
machine and the app is executed in a similar manner on the new host
if runtime.json is removed or reconfigured."

That's easier for me to read, but “in a similar manner” is wishy
enough that I'm not sure what the sentence clarifies. But that may
just be because I don't see a clear line around “runtime-specific”
1.

Sure, +1 on introducing the "application" as a noun in the spec.

wking · 2015-07-30T23:09:17Z

On Thu, Jul 30, 2015 at 12:43:27PM -0700, Brandon Philips wrote:

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.

“Inherently runtime specific” and “portable between hosts” both sound
like slippery slopes to me. For example, absolute-path hooks may not
be portable between hosts 1, but I doubt anyone would argue for the
hook declarations to be moved into a dynamic runtime.json. User/group
ID mappings are also likely to be imperfectly portable, and
environment variables may be runtime-specific. So I don't think
splitting the config into static/dynamic parts is going to add much
clarity or usability.

For dynamic cgroups, rlimits, etc., I've argued that we should just be
push/pulling that information from the kernel 2 or leaving
state-consumers to handle it directly 3.

For migration between hosts, I'm happy to jump through whatever hoops
CRIU requires, but it seems like any information that would need could
be copied out of the current config.json, /proc, and /sys. Is there
some part of this config/runtime split that makes CRIU easier?

In order to attach a cryptographic identity to a bundle we must not
include details in the bundle that are host specific.

For cryptographic identity, I don't see why we'd want to sign only
non-host-specific configs. A reasonable security model is probably to
have the agent making the host-specific adjustment do whatever they
feel is needed to verify the original bundle, and then have them vouch
for the host-adapted version that they right. In the absence of an
in-spec verification model (which I think is out of scope here [4,5]),
it's hard to address this directly. If you give more details about
the verification model you have in mind, I could try to sketch out the
re-signing in more detail.

mrunalp · 2015-07-31T16:07:44Z

runtime-config-linux.md

+            "path": "/proc/1234/ns/pid"
+        },
+        {
+            "type": "net",


I think namespaces are tricky because if the path isn't specified then they are portable.

@mrunalp Any suggestions on how to resolve this?

How about breaking it into two different structs? One for new namespaces and other for joining namespaces. Validation could check that there is no overlap for same namespace type in the two or there could be documented behavior on what has higher preference.

Sent from my iPhone

On Aug 4, 2015, at 9:47 PM, Brandon Philips [email protected] wrote:

In runtime-config-linux.md:

+instance of the global resource. Changes to the global resource are visible to
+other processes that are members of the namespace, but are invisible to other
+processes. For more information, see the man page
+
+Namespaces are specified in the spec as an array of entries. Each entry has a
+type field with possible values described below and an optional path element.
+If a path is specified, that particular file is used to join that type of namespace.
+
+```json

"namespaces": [

{

"type": "pid",

"path": "/proc/1234/ns/pid"

},

{

"type": "net",
@mrunalp Any suggestions on how to resolve this?

—
Reply to this email directly or view it on GitHub.

@mrunalp Hrm, is there a use case for the application to care what namespace it is in for pid, net, utc, ipc, or user? It seems like a runtime detail.

Btw I think that separate structs will be cleaner. Also I think it'd be pretty cool to have something portable about namespaces.

@LK4D4 What is a use case for an application to ask for a namespace explicitly besides the mount propagation? I am not opposed, but if we add it I want a use case in mind.

@philips The primary use case is joining the namespaces of other containers. For e.g. like how the pod infra container in kubernetes serves as the base container whose net and namespaces the other containers in the pod join.

i wonder if we can also use the same solution as mount points i.e. to give namespace a name and delegates the assignment of name to host path to the caller.
Or we requires the namespace path to be relative to the bundle i.e. user needs to bind-mount the namespaces.

philips · 2015-08-05T04:56:30Z

Does anyone else have comments on this approach? We need to establish a way of making the bundle actually portable across hosts and have a consistent way of establishing the identity of the bundle once it gets there.

mrunalp · 2015-08-05T16:47:12Z

runtime-config-linux.md

+
+rlimits allow setting resource limits. The type is from the values defined in [the man page](http://man7.org/linux/man-pages/man2/setrlimit.2.html). The kernel enforces the soft limit for a resource while the hard limit acts as a ceiling for that value that could be set by an unprivileged process.
+
+## Linux user namespace mappings


I think user namespace mappings could be in the portable section.

@mrunalp I don't think the mappings can be in the portable section because you won't know the uid/gid ranges available until you land on a host and find out the already consumed ranges. Perhaps you mean something else?

@philips What I was trying to say was that one could use the same mappings on any host and they would work assuming that the linux host has user namespaces enabled. I think you are referring to assigning a particular range to a container/cluster user and that may or may not be available on a host and hence isn't portable. One way to get around it is to just have users specify that they need a range of a particular length and then translate that to whatever is available on the host. However, that seems like a feature that belongs to higher level orchestration and it could be translated to non portable section of the OCI spec.

crosbymichael · 2015-08-06T18:06:20Z

Instead of two configs what do you think about making the single config portable by having the paths for binds and namespaces paths be relative to the container's dir?

LK4D4 · 2015-08-06T18:07:21Z

@crosbymichael @philips yup, and caller can like create symlinks or bindmounts there.

philips · 2015-08-06T20:33:32Z

@crosbymichael We need separate files because there will always be things that are local mounts is just one of those things. Other things include cgroup constraints, userns mapping, SELinux labels, etc.

If we don't have two separate files then we can't hash the application environment variables, environment, uid, etc into the identity of the bundle.

crosbymichael · 2015-08-06T20:36:56Z

@philips maybe relative paths for the host specific paths then the runtime config for things that can be updated that include alot of the "settings" vs "paths"?

philips · 2015-08-06T20:44:43Z

@crosbymichael Another approach: in appc every mount point has a name see mountpoints then you can fulfill those mounts at runtime with a host mount. This feels like a cleaner abstraction instead of having multiple bind mount to fulfill a single container mount.

For example the config.json would say:

        "mountPoints": [
            {
                "name": "work",
                "path": "/var/lib/work",
            }
        ],

Then the runtime would resolve this to a mount on the host. The name could be resolved via a bind mount directory, as you suggest, or as an entry in a runtime.json.

crosbymichael · 2015-08-07T18:14:24Z

@philips that does sound like a much better idea. +1!

vbatts · 2015-08-07T18:23:14Z

@philips yes. nice.

mrunalp · 2015-08-10T16:42:17Z

+1 and we could use the same technique to resolve other similar issues.

philips · 2015-08-11T04:53:25Z

rebased and added the mountPoint object. cleaning up some other nits and feedback.

And link them to the more detailed specification. This borrows from appc, which calls the launched process tree "the app" [1]. I don't see a point to abbreviating it, so I've gone with "application". Subsection titles for the entries will be obnoxiously spacious, but the other alternatives seem worse: a. An HTML definition list (<dl>) would have nice default styling, but it's annoying to write raw HTML. And we would have needed something like: <dt name="bundle">Bundle</dt> <dd> A [directory structure](bundle.md) that is... </dd> to get Markdown-style links in the defintion itself. b. A Markdown list (* ...) would have reasonable default styling, but there's no Markdown syntax for adding anchors to the entries. And a glossary is much less useful if you can't link to a specific entry. [1]: opencontainers#88 (comment) Signed-off-by: W. Trevor King <[email protected]>

wking · 2015-08-11T17:36:02Z

Spun back into the main thread, because the 88/files comment anchor
was rebased away 1.

On Mon, Aug 10, 2015 at 10:08:32PM -0700, Brandon Philips wrote 1:

-One or more content directories may be adjacent to the configuration file. This must include at least the root filesystem…
+This must include at least the root filesystem…

@wking I removed the "one or more content directories" language
because we removed the idea of "content directories" a while back in
the spec.

Did we? I think you can still put as many directories as you like
into the bundle, and you can use those directories as mount points, or
for non-runtime tooling (e.g. an external config-selection tool, #76).
I think it's important to keep that flexiblity explicit.

philips · 2015-08-12T17:25:27Z

TODO: Add language about bundle filesystem should have mapped the userns mappings already pre-executed

wking · 2015-08-12T18:32:33Z

On Wed, Aug 12, 2015 at 10:25:29AM -0700, Brandon Philips wrote:

TODO: Add language about bundle filesystem should have mapped the
userns mappings already pre-executed

Is that “if you intend file $x to be owned by root inside your
container, it needs to be uid 0 in your bundled filesystem on the
host, regardless of which host-side user is being mapped to the
container's root”. Is that actually true? It seems like something
that userns should be handling for us.

wking · 2015-08-24T16:25:02Z

On Wed, Aug 12, 2015 at 11:30:25AM -0700, W. Trevor King wrote:

Wed, Aug 12, 2015 at 10:25:29AM -0700, Brandon Philips:

TODO: Add language about bundle filesystem should have mapped the
userns mappings already pre-executed

Is that “if you intend file $x to be owned by root inside your
container, it needs to be uid 0 in your bundled filesystem on the
host, regardless of which host-side user is being mapped to the
container's root”. Is that actually true? It seems like something
that userns should be handling for us.

And indeed, it is something that userns handles for us. Using
userns_child_exec (source in user_namespaces(7) 1)

$ id -u 1000
$ touch example-1
$ ls -ln example-1
-rw-r--r-- 1 1000 1000 0 Aug 24 09:22 example-1
$ ./userns_child_exec -p -m -U -M '0 1000 1' -G '0 1000 1' bash

ls -ln example-1

-rw-r--r-- 1 0 0 0 Aug 24 09:22 example-1

echo hi >example-1

echo there >example-2

ls -ln example*

-rw-r--r-- 1 0 0 3 Aug 24 09:24 example-1
-rw-r--r-- 1 0 0 6 Aug 24 09:24 example-2

exit

$ ls -ln example*
-rw-r--r-- 1 1000 1000 3 Aug 24 09:24 example-1
-rw-r--r-- 1 1000 1000 6 Aug 24 09:24 example-2

So I see no need to map the host-side filesystem uids and gids.

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.

These snuck in with 7232e4b (specs: introduce the concept of a runtime.json, 2015-07-30, opencontainers#88) and 73bf1ba (JSON objects are easier to parse/manipulate, 2015-08-27, opencontainers#120). Signed-off-by: W. Trevor King <[email protected]>

And link them to the more detailed specification. This borrows from appc, which calls the launched process tree "the app" [1]. I don't see a point to abbreviating it, so I've gone with "application". Subsection titles for the entries will be obnoxiously spacious, but the other alternatives seem worse: a. An HTML definition list (<dl>) would have nice default styling, but it's annoying to write raw HTML. And we would have needed something like: <dt name="bundle">Bundle</dt> <dd> A [directory structure](bundle.md) that is... </dd> to get Markdown-style links in the defintion itself. b. A Markdown list (* ...) would have reasonable default styling, but there's no Markdown syntax for adding anchors to the entries. And a glossary is much less useful if you can't link to a specific entry. [1]: opencontainers#88 (comment) Signed-off-by: W. Trevor King <[email protected]>

Michael was adding these to existing Go files to avoid having a lot of files [1]. But 7232e4b (specs: introduce the concept of a runtime.json, 2015-07-30, opencontainers#88) split the runtime-configuration into two file sets (one rooted in config.go for config.json and another rooted in runtime_config.go for runtime.json). In the face of a two-set split for a single task (feeding the runtime while it manipulates the container lifecycle), it seems odd to push the type definition for a completely different task (sharing container/application state with other tools) into an existing file set. [1]: opencontainers#87 (comment) Signed-off-by: W. Trevor King <[email protected]>

And link them to the more detailed specification. This borrows from appc, which calls the launched process tree "the app" [1]. I don't see a point to abbreviating it, so I've gone with "application". Subsection titles for the entries will be obnoxiously spacious, but the other alternatives seem worse: a. An HTML definition list (<dl>) would have nice default styling, but it's annoying to write raw HTML. And we would have needed something like: <dt name="bundle">Bundle</dt> <dd> A [directory structure](bundle.md) that is... </dd> to get Markdown-style links in the defintion itself. b. A Markdown list (* ...) would have reasonable default styling, but there's no Markdown syntax for adding anchors to the entries. And a glossary is much less useful if you can't link to a specific entry. [1]: opencontainers#88 (comment) Signed-off-by: W. Trevor King <[email protected]>

Catch up with [1]. [1]: opencontainers/runtime-spec#88 Signed-off-by: W. Trevor King <[email protected]>

Reverting 7232e4b (specs: introduce the concept of a runtime.json, 2015-07-30, opencontainers#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 opencontainers#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 it's pre-7232e4b1 content. * Removed required mounts from the config example (requirements landed in 3848a23, config-linux: specify the default devices/filesystems available, 2015-09-09, opencontainers#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: <[email protected]>

Reverting 7232e4b (specs: introduce the concept of a runtime.json, 2015-07-30, opencontainers#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 opencontainers#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 3848a23, config-linux: specify the default devices/filesystems available, 2015-09-09, opencontainers#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: <[email protected]>

Reverting 7232e4b (specs: introduce the concept of a runtime.json, 2015-07-30, opencontainers#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 opencontainers#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 3848a23, config-linux: specify the default devices/filesystems available, 2015-09-09, opencontainers#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: <[email protected]> Signed-off-by: W. Trevor King <[email protected]>

Some history behind bundle requirements: * 77d44b1 (Update runtime.md, 2015-06-16) lands the initial reference to a root filesystem, requiring a relative path. It also lands the "bundle" construct, which at this point includes content directories, signatures, and the configuration file. The content directories "at least" include the root filesystem. * 5d2eb18 (*: re-org the spec, 2015-06-24) shifts the bundle docs to bundle.md and demotes signatures to "other related content". * 91f5ad7 (bundle.md: various updates to latest spec, 2015-07-02, opencontainers#55) finishes the signature demotion and strengthens the root-inclusion requirement with another "must include". * 7232e4b (specs: introduce the concept of a runtime.json, 2015-07-30, opencontainers#88) split out runtime.json, required the root directory to exist at `rootfs`, and dropped most references to "content directories". * 106ec2d (Cleanup bundle.md, 2015-10-02, opencontainers#210) kept the requirement for a rootfs directory in the bundle root, but relaxed the name requirement to allow other single-component names (e.g. `my-rootfs`). Dropped the last reference to "content directories". * cb2da54 (config: Single, unified config file, 2015-12-28, opencontainers#284) rolled runtime.json back into config.json. * b2e9154 (Remove requirement for rootfs path to be relative, 2016-04-22, opencontainers#394) allowed absolute paths for root.path and removed some "same directory" language while leaving other "same directory" language. I think the root filesystem should be optional [1], but even folks who disagree on that point have come to the conclusion that it doesn't need to be in the bundle [2]. opencontainers#394 seems partially unfinished, but I think the intention was clear. Once you relax the "bundle must contain the root filesystem" requirement, the only thing that the bundle must contain is config.json. It doesn't seem to be worth the trouble to name a "bundle" construct if its only meaning is "the directory that holds config.json", so this commit removes all remaining references to the term "bundle". [1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/6ZKMNWujDhU Subject: Dropping the rootfs requirement and restoring arbitrary bundle content Date: Wed, 26 Aug 2015 12:54:47 -0700 Message-ID: <[email protected]> [2]: opencontainers#389 (comment) Signed-off-by: W. Trevor King <[email protected]>

Reverting 7232e4b (specs: introduce the concept of a runtime.json, 2015-07-30, opencontainers#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 opencontainers#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 3848a23, config-linux: specify the default devices/filesystems available, 2015-09-09, opencontainers#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: <[email protected]> Signed-off-by: W. Trevor King <[email protected]>

wking reviewed Jul 30, 2015
View reviewed changes

mrunalp reviewed Jul 31, 2015
View reviewed changes

mrunalp reviewed Aug 5, 2015
View reviewed changes

philips force-pushed the runtime-vs-app-config branch from 49ce63d to 2503155 Compare August 11, 2015 04:52

philips force-pushed the runtime-vs-app-config branch 2 times, most recently from b45cd17 to ba6d0ee Compare August 11, 2015 05:07

wking mentioned this pull request Aug 11, 2015

glossary: Provide a quick overview of important terms #107

Merged

philips changed the title ~~WIP specs: introduce the concept of a runtime.json~~ specs: introduce the concept of a runtime.json Aug 12, 2015

This was referenced Aug 15, 2015

Dependencies/layers? #57

Closed

Add extra file descriptors to Process #100

Closed

philips force-pushed the runtime-vs-app-config branch from ba6d0ee to 7232e4b Compare August 26, 2015 16:44

This was referenced Aug 29, 2015

runtime-config: Remove blank lines from the end of files #122

Merged

Adjust filesnames to match associated JSON #126

Closed

wking mentioned this pull request Sep 2, 2015

Change layout of mountpoints and mounts #136

Merged

wking mentioned this pull request Sep 3, 2015

state: Shift the state tree to it's own set of files #143

Closed

wking mentioned this pull request Oct 6, 2015

Cleanup bundle.md #210

Merged

wking mentioned this pull request Oct 28, 2015

Add lifecycle for containers #231

Merged

wking added a commit to wking/oci-command-line-api that referenced this pull request Dec 2, 2015

Link to runtime.json too

f554af8

Catch up with [1]. [1]: opencontainers/runtime-spec#88 Signed-off-by: W. Trevor King <[email protected]>

wking added a commit to wking/oci-command-line-api that referenced this pull request Dec 2, 2015

Link to runtime.json too

a7f5aa9

Catch up with [1]. [1]: opencontainers/runtime-spec#88 Signed-off-by: W. Trevor King <[email protected]>

wking mentioned this pull request Dec 28, 2015

config: Single, unified config file #284

Merged

wking mentioned this pull request May 3, 2016

artifacts must be present in a single directory opencontainers/runtime-tools#55

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

specs: introduce the concept of a runtime.json #88

specs: introduce the concept of a runtime.json #88

philips commented Jul 30, 2015

wking Jul 30, 2015

philips Aug 5, 2015

wking Aug 5, 2015

philips Aug 11, 2015

wking commented Jul 30, 2015

mrunalp Jul 31, 2015

philips Aug 5, 2015

mrunalp Aug 5, 2015

philips Aug 11, 2015

LK4D4 Aug 11, 2015

philips Aug 11, 2015

mrunalp Aug 11, 2015

dqminh Aug 11, 2015

philips commented Aug 5, 2015

mrunalp Aug 5, 2015

philips Aug 11, 2015

mrunalp Aug 11, 2015

crosbymichael commented Aug 6, 2015

LK4D4 commented Aug 6, 2015

philips commented Aug 6, 2015

crosbymichael commented Aug 6, 2015

philips commented Aug 6, 2015

crosbymichael commented Aug 7, 2015

vbatts commented Aug 7, 2015

mrunalp commented Aug 10, 2015

philips commented Aug 11, 2015

wking commented Aug 11, 2015

philips commented Aug 12, 2015

wking commented Aug 12, 2015

wking commented Aug 24, 2015


		rlimits allow setting resource limits. The type is from the values defined in [the man page](http://man7.org/linux/man-pages/man2/setrlimit.2.html). The kernel enforces the soft limit for a resource while the hard limit acts as a ceiling for that value that could be set by an unprivileged process.

		## Linux user namespace mappings

specs: introduce the concept of a runtime.json #88

specs: introduce the concept of a runtime.json #88

Conversation

philips commented Jul 30, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wking commented Jul 30, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

philips commented Aug 5, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

crosbymichael commented Aug 6, 2015

LK4D4 commented Aug 6, 2015

philips commented Aug 6, 2015

crosbymichael commented Aug 6, 2015

philips commented Aug 6, 2015

crosbymichael commented Aug 7, 2015

vbatts commented Aug 7, 2015

mrunalp commented Aug 10, 2015

philips commented Aug 11, 2015

wking commented Aug 11, 2015

philips commented Aug 12, 2015

wking commented Aug 12, 2015

wking commented Aug 24, 2015

ls -ln example-1

echo hi >example-1

echo there >example-2

ls -ln example*

exit