Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions config.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ For example, if a configuration is compliant with version 1.1 of this specificat
"ociVersion": "0.1.0"
```

## Root Configuration
## Root

**`root`** (object, REQUIRED) configures the container's root filesystem.

Expand All @@ -41,7 +41,7 @@ For example, if a configuration is compliant with version 1.1 of this specificat

## Mounts

**`mounts`** (array, OPTIONAL) configures additional mounts (on top of [`root`](#root-configuration)).
**`mounts`** (array, OPTIONAL) configures additional mounts (on top of [`root`](#root)).
The runtime MUST mount entries in the listed order.
The parameters are similar to the ones in [the Linux mount system call](http://man7.org/linux/man-pages/man2/mount.2.html).
For Solaris, the mounts corresponds to fs resource in zonecfg(8).
Expand Down
126 changes: 124 additions & 2 deletions runtime.md
Original file line number Diff line number Diff line change
Expand Up @@ -121,11 +121,133 @@ When the process in the container is stopped, irrespective of it being as a resu
This operation MUST generate an error if it is not provided the container ID.
Attempting to delete a container that does not exist MUST generate an error.
Attempting to delete a container whose process is still running MUST generate an error.
Deleting a container MUST delete the resources that were created during the `create` step.
Note that resources associated with the container, but not created by this container, MUST NOT be deleted.
Once a container is deleted its ID MAY be used by a subsequent container.

Deleting a container MUST delete the resources that were created during the `create` step.
Resources associated with the container, but not created by this container, MUST NOT be altered.

#### Examples of resource ownership
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why we should have examples like this in the spec at all. Its too much overspecifying things and your descriptions are wrong anyways on how namespaces are "destroyed".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My example I know we have examples in the repo showing off how to populate fields but examples like this describing functionality/implementation don't belong in my opinion.


This section contains informative elaborations of the above “resources created by the container” requirements.
It is not intended to be exhaustive.

##### Joining mount namespaces (Linux)

A container joins an existing [mount namespace](config-linux.md#namespaces) on Linux and pivots [root](config.md#root) into the `rootfs` directory with the following [configuration](config.md):

```json
{
"ociVersion": "1.0.0-rc3",
"platform": {
"os": "linux",
"arch": "amd64"
},
"process": {
"cwd": "/",
"args": [
"sh"
],
"user": {
"uid": 1,
"gid": 1
}
},
"root": {
"path": "rootfs"
},
"linux": {
"namespaces": [
{
"type": "mount",
"path": "/proc/1234/ns/mnt"
}
]
}
}
```

When the example container is deleted, neither removing the preexisting mount namespace nor undoing the pivot into `rootfs` are allowed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think deleting namespace is a bit overly specified, it probably is not true since on Linux, namespace is destroyed when the last process that is a member of the namespace terminates.

So if we join a shared namespace and the original container exits, our container's terminates will delete this namespace, and that's something we should not interfere.


##### Joining UTS namespaces (Linux)

A container joins an existing [UTS namespace](config-linux.md#namespaces) on Linux and changes the [hostname](config.md#hostname) with the following [configuration](config.md):

```json
{
"ociVersion": "1.0.0-rc3",
"platform": {
"os": "linux",
"arch": "amd64"
},
"process": {
"cwd": "/",
"args": [
"sh"
],
"user": {
"uid": 1,
"gid": 1
}
},
"root": {
"path": "rootfs"
},
"hostname": "alice",
"linux": {
"namespaces": [
{
"type": "uts",
"path": "/proc/1234/ns/uts"
},
{
"type": "mount"
}
]
}
}
```

When the example container is deleted, neither removing the preexisting UTS namespace nor undoing the hostname change are allowed.

##### Joining cgroups (Linux)

A container joins an existing [cgroup](config-linux.md#control-groups) on Linux and changes a [memory limit](config.md#memory) with the following [configuration](config.md):

```json
{
"ociVersion": "1.0.0-rc3",
"platform": {
"os": "linux",
"arch": "amd64"
},
"process": {
"cwd": "/",
"args": [
"sh"
],
"user": {
"uid": 1,
"gid": 1
}
},
"root": {
"path": "rootfs"
},
"linux": {
"cgroupsPath": "/some/existing/container",
"resources": {
"memory": {
"limit": 100000
}
}
}
}
```

When the example container is deleted, neither removing the preexisting cgroup not undoing the memory limit change are allowed.

## Hooks
Many of the operations specified in this specification have "hooks" that allow for additional actions to be taken before or after each operation.
See [runtime configuration for hooks](./config.md#hooks) for more information.

[container-namespace3]: glossary.md#container-namespace