Skip to content

Commit

Permalink
format specs with 4 spaces indent
Browse files Browse the repository at this point in the history 
Signed-off-by: Ma Shimiao <[email protected]>
  • Loading branch information
Ma Shimiao authored and Ma Shimiao committed Jun 1, 2017
1 parent ec44a7e commit 137b9c3
Show file tree
Hide file tree
Showing 8 changed files with 149 additions and 161 deletions.
2 changes: 1 addition & 1 deletion README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -145,7 +145,7 @@ Read more on [How to Write a Git Commit Message][how-to-git-commit] or the Discu
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how
* If there was important/useful/essential conversation or information, copy or include a reference
* If there was important/useful/essential conversation or information, copy or include a reference
8. When possible, one keyword to scope the change in the subject (i.e. "README: ...", "runtime: ...")


Expand Down
6 changes: 3 additions & 3 deletions RELEASES.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -43,9 +43,9 @@ Specifications have a variety of different timelines in their lifecycle.

* Pre-v1.0.0 specifications SHOULD release on a monthly cadence to garner feedback.
* Major specification releases MUST release at least three release candidates spaced a minimum of one week apart.
This means a major release like a v1.0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself.
Maintainers SHOULD strive to make zero breaking changes during this cycle of release candidates and SHOULD restart the three-candidate count when a breaking change is introduced.
For example if a breaking change is introduced in v1.0.0-rc2 then the series would end with v1.0.0-rc4 and v1.0.0.
This means a major release like a v1.0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself.
Maintainers SHOULD strive to make zero breaking changes during this cycle of release candidates and SHOULD restart the three-candidate count when a breaking change is introduced.
For example if a breaking change is introduced in v1.0.0-rc2 then the series would end with v1.0.0-rc4 and v1.0.0.
- Minor and patch releases SHOULD be made on an as-needed basis.

[charter]: https://www.opencontainers.org/about/governance
7 changes: 4 additions & 3 deletions bundle.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -11,11 +11,12 @@ A Standard Container bundle contains all the information needed to load and run
This includes the following artifacts:

1. <a name="containerFormat01" />`config.json`: contains configuration data.
This REQUIRED file MUST reside in the root of the bundle directory and MUST be named `config.json`.
See [`config.json`](config.md) for more details.
This REQUIRED file MUST reside in the root of the bundle directory and MUST be named `config.json`.
See [`config.json`](config.md) for more details.

2. <a name="containerFormat02" />A directory representing the root filesystem of the container.
On Windows, for Windows Server containers, this directory is REQUIRED. For Hyper-V containers, it MUST be omitted.
On Windows, for Windows Server containers, this directory is REQUIRED.
For Hyper-V containers, it MUST be omitted.

On all other platforms, this field is REQUIRED.

Expand Down
111 changes: 46 additions & 65 deletions config-linux.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -115,12 +115,12 @@ The runtime may supply them however it likes (with [mknod][mknod.2], by bind mou
Each entry has the following structure:

* **`type`** *(string, REQUIRED)* - type of device: `c`, `b`, `u` or `p`.
More info in [mknod(1)][mknod.1].
More info in [mknod(1)][mknod.1].
* **`path`** *(string, REQUIRED)* - full path to device inside container.
If a [file][] already exists at `path` that does not match the requested device, the runtime MUST generate an error.
If a [file][] already exists at `path` that does not match the requested device, the runtime MUST generate an error.
* **`major, minor`** *(int64, REQUIRED unless `type` is `p`)* - [major, minor numbers][devices] for the device.
* **`fileMode`** *(uint32, OPTIONAL)* - file mode for the device.
You can also control access to devices [with cgroups](#device-whitelist).
You can also control access to devices [with cgroups](#device-whitelist).
* **`uid`** *(uint32, OPTIONAL)* - id of device owner.
* **`gid`** *(uint32, OPTIONAL)* - id of device group.

Expand All @@ -129,7 +129,7 @@ The same `type`, `major` and `minor` SHOULD NOT be used for multiple devices.
### Example

```json
"devices": [
"devices": [
{
"path": "/dev/fuse",
"type": "c",
Expand Down Expand Up @@ -194,18 +194,18 @@ Runtimes MAY attach the container process to additional cgroup controllers beyon
### Example

```json
"cgroupsPath": "/myRuntime/myContainer",
"resources": {
"memory": {
"limit": 100000,
"reservation": 200000
},
"devices": [
{
"allow": false,
"access": "rwm"
}
]
"cgroupsPath": "/myRuntime/myContainer",
"resources": {
"memory": {
"limit": 100000,
"reservation": 200000
},
"devices": [
{
"allow": false,
"access": "rwm"
}
]
}
```

Expand All @@ -218,16 +218,16 @@ Each entry has the following structure:

* **`allow`** *(boolean, REQUIRED)* - whether the entry is allowed or denied.
* **`type`** *(string, OPTIONAL)* - type of device: `a` (all), `c` (char), or `b` (block).
Unset values mean "all", mapping to `a`.
Unset values mean "all", mapping to `a`.
* **`major, minor`** *(int64, OPTIONAL)* - [major, minor numbers][devices] for the device.
Unset values mean "all", mapping to [`*` in the filesystem API][cgroup-v1-devices].
Unset values mean "all", mapping to [`*` in the filesystem API][cgroup-v1-devices].
* **`access`** *(string, OPTIONAL)* - cgroup permissions for device.
A composition of `r` (read), `w` (write), and `m` (mknod).
A composition of `r` (read), `w` (write), and `m` (mknod).

#### Example

```json
"devices": [
"devices": [
{
"allow": false,
"access": "rwm"
Expand Down Expand Up @@ -273,15 +273,10 @@ For more information, see the kernel cgroups documentation about [memory][cgroup
The following parameters can be specified to set up the controller:

* **`limit`** *(uint64, OPTIONAL)* - sets limit of memory usage in bytes

* **`reservation`** *(uint64, OPTIONAL)* - sets soft limit of memory usage in bytes

* **`swap`** *(uint64, OPTIONAL)* - sets limit of memory+Swap usage

* **`kernel`** *(uint64, OPTIONAL)* - sets hard limit for kernel memory

* **`kernelTCP`** *(uint64, OPTIONAL)* - sets hard limit in bytes for kernel TCP buffer memory

* **`swappiness`** *(uint64, OPTIONAL)* - sets swappiness parameter of vmscan (See sysctl's vm.swappiness)

#### Example
Expand All @@ -305,17 +300,11 @@ For more information, see the kernel cgroups documentation about [cpusets][cgrou
The following parameters can be specified to set up the controller:

* **`shares`** *(uint64, OPTIONAL)* - specifies a relative share of CPU time available to the tasks in a cgroup

* **`quota`** *(int64, OPTIONAL)* - specifies the total amount of time in microseconds for which all tasks in a cgroup can run during one period (as defined by **`period`** below)

* **`period`** *(uint64, OPTIONAL)* - specifies a period of time in microseconds for how regularly a cgroup's access to CPU resources should be reallocated (CFS scheduler only)

* **`realtimeRuntime`** *(int64, OPTIONAL)* - specifies a period of time in microseconds for the longest continuous period in which the tasks in a cgroup have access to CPU resources

* **`realtimePeriod`** *(uint64, OPTIONAL)* - same as **`period`** but applies to realtime scheduler only

* **`cpus`** *(string, OPTIONAL)* - list of CPUs the container will run in

* **`mems`** *(string, OPTIONAL)* - list of Memory Nodes the container will run in

#### Example
Expand All @@ -340,9 +329,7 @@ For more information, see the kernel cgroups documentation about [blkio][cgroup-
The following parameters can be specified to set up the controller:

* **`blkioWeight`** *(uint16, OPTIONAL)* - specifies per-cgroup weight. This is default weight of the group on all devices until and unless overridden by per-device rules.

* **`blkioLeafWeight`** *(uint16, OPTIONAL)* - equivalents of `blkioWeight` for the purpose of deciding how much weight tasks in the given cgroup has while competing with the cgroup's child cgroups.

* **`blkioWeightDevice`** *(array of objects, OPTIONAL)* - specifies the list of devices which will be bandwidth rate limited. The following parameters can be specified per-device:
* **`major, minor`** *(int64, REQUIRED)* - major, minor numbers for device. More info in [mknod(1)][mknod.1] man page.
* **`weight`** *(uint16, OPTIONAL)* - bandwidth rate for the device.
Expand All @@ -351,7 +338,7 @@ The following parameters can be specified to set up the controller:
You MUST specify at least one of `weight` or `leafWeight` in a given entry, and MAY specify both.

* **`blkioThrottleReadBpsDevice`**, **`blkioThrottleWriteBpsDevice`**, **`blkioThrottleReadIOPSDevice`**, **`blkioThrottleWriteIOPSDevice`** *(array of objects, OPTIONAL)* - specify the list of devices which will be IO rate limited.
The following parameters can be specified per-device:
The following parameters can be specified per-device:
* **`major, minor`** *(int64, REQUIRED)* - major, minor numbers for device. More info in [mknod(1)][mknod.1] man page.
* **`rate`** *(uint64, REQUIRED)* - IO rate limit for the device

Expand Down Expand Up @@ -400,13 +387,12 @@ For more information, see the kernel cgroups documentation about [HugeTLB][cgrou
Each entry has the following structure:

* **`pageSize`** *(string, REQUIRED)* - hugepage size

* **`limit`** *(uint64, REQUIRED)* - limit in bytes of *hugepagesize* HugeTLB usage

#### Example

```json
"hugepageLimits": [
"hugepageLimits": [
{
"pageSize": "2MB",
"limit": 209715200
Expand All @@ -422,16 +408,15 @@ For more information, see the kernel cgroups documentations about [net\_cls cgro
The following parameters can be specified to set up the controller:

* **`classID`** *(uint32, OPTIONAL)* - is the network class identifier the cgroup's network packets will be tagged with

* **`priorities`** *(array of objects, OPTIONAL)* - specifies a list of objects of the priorities assigned to traffic originating from processes in the group and egressing the system on various interfaces.
The following parameters can be specified per-priority:
The following parameters can be specified per-priority:
* **`name`** *(string, REQUIRED)* - interface name in [runtime network namespace](glossary.md#runtime-namespace)
* **`priority`** *(uint32, REQUIRED)* - priority applied to the interface

#### Example

```json
"network": {
"network": {
"classID": 1048577,
"priorities": [
{
Expand All @@ -458,7 +443,7 @@ The following parameters can be specified to set up the controller:
#### Example

```json
"pids": {
"pids": {
"limit": 32771
}
```
Expand Down Expand Up @@ -499,7 +484,7 @@ For more information, see the [sysctl(8)][sysctl.8] man page.
### Example

```json
"sysctl": {
"sysctl": {
"net.ipv4.ip_forward": "1",
"net.core.somaxconn": "256"
}
Expand Down Expand Up @@ -549,7 +534,6 @@ The following parameters can be specified to set up seccomp:

* **`names`** *(array of strings, REQUIRED)* - the names of the syscalls.
`names` MUST contain at least one entry.

* **`action`** *(string, REQUIRED)* - the action for seccomp rules.
A valid list of constants as of libseccomp v2.3.2 is shown below.

Expand All @@ -564,11 +548,8 @@ The following parameters can be specified to set up seccomp:
Each entry has the following structure:

* **`index`** *(uint, REQUIRED)* - the index for syscall arguments in seccomp.

* **`value`** *(uint64, REQUIRED)* - the value for syscall arguments in seccomp.

* **`valueTwo`** *(uint64, REQUIRED)* - the value for syscall arguments in seccomp.

* **`op`** *(string, REQUIRED)* - the operator for syscall arguments in seccomp.
A valid list of constants as of libseccomp v2.3.2 is shown below.

Expand All @@ -583,29 +564,29 @@ The following parameters can be specified to set up seccomp:
### Example

```json
"seccomp": {
"defaultAction": "SCMP_ACT_ALLOW",
"architectures": [
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"getcwd",
"chmod"
],
"action": "SCMP_ACT_ERRNO"
}
]
}
"seccomp": {
"defaultAction": "SCMP_ACT_ALLOW",
"architectures": [
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"getcwd",
"chmod"
],
"action": "SCMP_ACT_ERRNO"
}
]
}
```

## <a name="configLinuxRootfsMountPropagation" />Rootfs Mount Propagation

**`rootfsPropagation`** (string, OPTIONAL) sets the rootfs's mount propagation.
Its value is either slave, private, shared or unbindable.
The [Shared Subtrees][sharedsubtree] article in the kernel documentation has more information about mount propagation.
Its value is either slave, private, shared or unbindable.
The [Shared Subtrees][sharedsubtree] article in the kernel documentation has more information about mount propagation.

### Example

Expand All @@ -616,7 +597,7 @@ The [Shared Subtrees][sharedsubtree] article in the kernel documentation has mor
## <a name="configLinuxMaskedPaths" />Masked Paths

**`maskedPaths`** (array of strings, OPTIONAL) will mask over the provided paths inside the container so that they cannot be read.
The values MUST be absolute paths in the [container namespace](glossary.md#container_namespace).
The values MUST be absolute paths in the [container namespace](glossary.md#container_namespace).

### Example

Expand All @@ -629,7 +610,7 @@ The values MUST be absolute paths in the [container namespace](glossary.md#conta
## <a name="configLinuxReadonlyPaths" />Readonly Paths

**`readonlyPaths`** (array of strings, OPTIONAL) will set the provided paths as readonly inside the container.
The values MUST be absolute paths in the [container namespace](glossary.md#container-namespace).
The values MUST be absolute paths in the [container namespace](glossary.md#container-namespace).

### Example

Expand Down
24 changes: 12 additions & 12 deletions config-solaris.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -83,21 +83,21 @@ For additional information on properties, check the [zonecfg(1M)][zonecfg.1m_2]
* **`linkname`** *(string, OPTIONAL)* Specify a name for the automatically created VNIC datalink.
* **`lowerLink`** *(string, OPTIONAL)* Specify the link over which the VNIC will be created.
Mapped to `lower-link` in the [zonecfg(1M)][zonecfg.1m_2] man page.
* **`allowedAddress`** *(string, OPTIONAL)* The set of IP addresses that the container can use might be constrained by specifying the allowedAddress property.
If allowedAddress has not been specified, then they can use any IP address on the associated physical interface for the network resource.
Otherwise, when allowedAddress is specified, the container cannot use IP addresses that are not in the allowedAddress list for the physical address.
Mapped to `allowed-address` in the [zonecfg(1M)][zonecfg.1m_2] man page.
* **`configureAllowedAddress`** *(string, OPTIONAL)* If configureAllowedAddress is set to true, the addresses specified by allowedAddress are automatically configured on the interface each time the container starts.
When it is set to false, the allowedAddress will not be configured on container start.
Mapped to `configure-allowed-address` in the [zonecfg(1M)][zonecfg.1m_2] man page.
* **`allowedAddress`** *(string, OPTIONAL)* The set of IP addresses that the container can use might be constrained by specifying the `allowedAddress` property.
If `allowedAddress` has not been specified, then they can use any IP address on the associated physical interface for the network resource.
Otherwise, when `allowedAddress` is specified, the container cannot use IP addresses that are not in the `allowedAddress` list for the physical address.
Mapped to `allowed-address` in the [zonecfg(1M)][zonecfg.1m_2] man page.
* **`configureAllowedAddress`** *(string, OPTIONAL)* If `configureAllowedAddress` is set to true, the addresses specified by `allowedAddress` are automatically configured on the interface each time the container starts.
When it is set to false, the `allowedAddress` will not be configured on container start.
Mapped to `configure-allowed-address` in the [zonecfg(1M)][zonecfg.1m_2] man page.
* **`defrouter`** *(string, OPTIONAL)* The value for the OPTIONAL default router.
* **`macAddress`** *(string, OPTIONAL)* Set the VNIC's MAC addresses based on the specified value or keyword.
If not a keyword, it is interpreted as a unicast MAC address.
For a list of the supported keywords please refer to the [zonecfg(1M)][zonecfg.1m_2] man page of the respective Solaris release.
Mapped to `mac-address` in the [zonecfg(1M)][zonecfg.1m_2] man page.
If not a keyword, it is interpreted as a unicast MAC address.
For a list of the supported keywords please refer to the [zonecfg(1M)][zonecfg.1m_2] man page of the respective Solaris release.
Mapped to `mac-address` in the [zonecfg(1M)][zonecfg.1m_2] man page.
* **`linkProtection`** *(string, OPTIONAL)* Enables one or more types of link protection using comma-separated values.
See the protection property in dladm(8) for supported values in respective release of Solaris.
Mapped to `link-protection` in the [zonecfg(1M)][zonecfg.1m_2] man page.
See the protection property in dladm(8) for supported values in respective release of Solaris.
Mapped to `link-protection` in the [zonecfg(1M)][zonecfg.1m_2] man page.

#### Example
```json
Expand Down
14 changes: 7 additions & 7 deletions config-windows.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -50,9 +50,7 @@ The following parameters can be specified:
The following parameters can be specified:

* **`count`** *(uint64, OPTIONAL)* - specifies the number of CPUs available to the container.

* **`shares`** *(uint16, OPTIONAL)* - specifies the relative weight to other containers with CPU shares.

* **`maximum`** *(uint, OPTIONAL)* - specifies the portion of processor cycles that this container can use as a percentage times 100.

#### Example
Expand All @@ -74,9 +72,7 @@ The following parameters can be specified:
The following parameters can be specified:

* **`iops`** *(uint64, OPTIONAL)* - specifies the maximum IO operations per second for the system drive of the container.

* **`bps`** *(uint64, OPTIONAL)* - specifies the maximum bytes per second for the system drive of the container.

* **`sandboxSize`** *(uint64, OPTIONAL)* - specifies the minimum size of the system drive in bytes.

#### Example
Expand Down Expand Up @@ -158,11 +154,15 @@ You can indicate that a container should be started in an a mode where disk flus

## <a name="configWindowsHyperV" />HyperV

`hyperv` is an OPTIONAL field of the Windows configuration. If present, the container MUST be run with Hyper-V isolation. If omitted, the container MUST be run as a Windows Server container.
`hyperv` is an OPTIONAL field of the Windows configuration.
If present, the container MUST be run with Hyper-V isolation.
If omitted, the container MUST be run as a Windows Server container.

The following parameters can be specified:

* **`utilityVMPath`** *(string, OPTIONAL)* - specifies the path to the image used for the utility VM. This would be specified if using a base image which does not contain a utility VM image. If not supplied, the runtime will search the container filesystem layers from the bottom-most layer upwards, until it locates "UtilityVM", and default to that path.
* **`utilityVMPath`** *(string, OPTIONAL)* - specifies the path to the image used for the utility VM.
This would be specified if using a base image which does not contain a utility VM image.
If not supplied, the runtime will search the container filesystem layers from the bottom-most layer upwards, until it locates "UtilityVM", and default to that path.

### Example

Expand All @@ -172,4 +172,4 @@ The following parameters can be specified:
"utilityVMPath": "C:\\path\\to\\utilityvm"
}
}
```
```
Loading

0 comments on commit 137b9c3

Please sign in to comment.