Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

tfix: replace setup #822

Merged
merged 1 commit into from
May 23, 2017
Merged

tfix: replace setup #822

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
18 changes: 9 additions & 9 deletions config-linux.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ The Linux container specification uses various kernel features like namespaces,
## <a name="configLinuxDefaultFilesystems" />Default Filesystems

The Linux ABI includes both syscalls and several special file paths.
Applications expecting a Linux environment will very likely expect these file paths to be setup correctly.
Applications expecting a Linux environment will very likely expect these file paths to be set up correctly.

The following filesystems SHOULD be made available in each container's filesystem:

Expand All @@ -24,7 +24,7 @@ Changes to the global resource are visible to other processes that are members o
For more information, see the [namespaces(7)][namespaces.7_2] man page.

Namespaces are specified as an array of entries inside the `namespaces` root field.
The following parameters can be specified to setup namespaces:
The following parameters can be specified to set up namespaces:
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd prefer we use “configure” in the sub-properties template. Also looking at parameter vs. property vs. field:

$ git describe
v1.0.0-rc5-162-g4aed614
$ git grep -i propert *.md | wc -l
23
$ git grep -i parameter *.md | wc -l
19
$ git grep -i field *.md | wc -l
18

So I'd like a template like:

The following properties can be specified to configure {thing}.

In this case that would be:

The following properties can be specified to configure namespaces:

But this is just me trying to copy-edit for consistency. The lines are clear as they stand, and slightly more clear with just the “setup” → “set up” change.


* **`type`** *(string, REQUIRED)* - namespace type. The following namespace types are supported:
* **`pid`** processes inside the container will only be able to see other processes inside the same container.
Expand Down Expand Up @@ -161,7 +161,7 @@ In addition to any devices configured with this setting, the runtime MUST also s
* [`/dev/random`][random.4]
* [`/dev/urandom`][random.4]
* [`/dev/tty`][tty.4]
* [`/dev/console`][console.4] is setup if terminal is enabled in the config by bind mounting the pseudoterminal slave to /dev/console.
* [`/dev/console`][console.4] is set up if terminal is enabled in the config by bind mounting the pseudoterminal slave to /dev/console.
* [`/dev/ptmx`][pts.4].
A [bind-mount or symlink of the container's `/dev/pts/ptmx`][devpts].

Expand Down Expand Up @@ -270,7 +270,7 @@ For more information, see [the memory cgroup man page][cgroup-v1-memory].
**`memory`** (object, OPTIONAL) represents the cgroup subsystem `memory` and it's used to set limits on the container's memory usage.
For more information, see [the memory cgroup man page][cgroup-v1-memory].

The following parameters can be specified to setup the controller:
The following parameters can be specified to set up the controller:

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

Expand Down Expand Up @@ -302,7 +302,7 @@ The following parameters can be specified to setup the controller:
**`cpu`** (object, OPTIONAL) represents the cgroup subsystems `cpu` and `cpusets`.
For more information, see [the cpusets cgroup man page][cgroup-v1-cpusets].

The following parameters can be specified to setup the controller:
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

Expand Down Expand Up @@ -337,7 +337,7 @@ The following parameters can be specified to setup the controller:
**`blockIO`** (object, OPTIONAL) represents the cgroup subsystem `blkio` which implements the block IO controller.
For more information, see [the kernel cgroups documentation about blkio][cgroup-v1-blkio].

The following parameters can be specified to setup the controller:
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.

Expand Down Expand Up @@ -419,7 +419,7 @@ Each entry has the following structure:
**`network`** (object, OPTIONAL) represents the cgroup subsystems `net_cls` and `net_prio`.
For more information, see [the net\_cls cgroup man page][cgroup-v1-net-cls] and [the net\_prio cgroup man page][cgroup-v1-net-prio].

The following parameters can be specified to setup the controller:
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

Expand Down Expand Up @@ -451,7 +451,7 @@ The following parameters can be specified to setup the controller:
**`pids`** (object, OPTIONAL) represents the cgroup subsystem `pids`.
For more information, see [the pids cgroup man page][cgroup-v1-pids].

The following parameters can be specified to setup the controller:
The following parameters can be specified to set up the controller:

* **`limit`** *(int64, REQUIRED)* - specifies the maximum number of tasks in the cgroup

Expand Down Expand Up @@ -514,7 +514,7 @@ The actions, architectures, and operators are strings that match the definitions

**`seccomp`** (object, OPTIONAL)

The following parameters can be specified to setup seccomp:
The following parameters can be specified to set up seccomp:

* **`defaultAction`** *(string, REQUIRED)* - the default action for seccomp. Allowed values are the same as `syscalls[].action`.

Expand Down
4 changes: 2 additions & 2 deletions config-solaris.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -70,14 +70,14 @@ cappedMemory is mapped to `capped-memory` in [zonecfg(1M)][zonecfg.1m_2] man pag
## <a name="configSolarisNetwork" />Network

### <a name="configSolarisAutomaticNetwork" />Automatic Network (anet)
anet is specified as an array that is used to setup networking for Solaris application containers.
anet is specified as an array that is used to set up networking for Solaris application containers.
The anet resource represents the automatic creation of a network resource for an application container.
The zones administration daemon, zoneadmd, is the primary process for managing the container's virtual platform.
One of the daemon's responsibilities is creation and teardown of the networks for the container.
For more information on the daemon see the [zoneadmd(1M)][zoneadmd.1m] man page.
When such a container is started, a temporary VNIC(Virtual NIC) is automatically created for the container.
The VNIC is deleted when the container is torn down.
The following properties can be used to setup automatic networks.
The following properties can be used to set up automatic networks.
For additional information on properties, check the [zonecfg(1M)][zonecfg.1m_2] man page for the respective release of Solaris.

* **`linkname`** *(string, OPTIONAL)* Specify a name for the automatically created VNIC datalink.
Expand Down