vbatts/cri-o
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

vendor: remove dep and use vndr

Browse source 
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
This commit is contained in:
Antonio Murdaca 2017-06-06 09:19:04 +02:00
parent 16f44674a4
commit 148e72d81e
No known key found for this signature in database
GPG key ID: B2BEAD150DE936B9
16131 changed files with 73815 additions and 4235138 deletions
Download patch file Download diff file Expand all files Collapse all files

3
vendor/github.com/opencontainers/runtime-spec/.gitignore generated vendored
View file

@ -1,3 +0,0 @@
output
schema/validate
version.md

12
vendor/github.com/opencontainers/runtime-spec/.pullapprove.yml generated vendored
View file

@ -1,12 +0,0 @@
approve_by_comment: true
approve_regex: ^LGTM
reject_regex: ^Rejected
reset_on_push: true
author_approval: ignored
signed_off_by:
required: true
reviewers:
teams:
- runtime-spec-maintainers
name: default
required: 2

25
vendor/github.com/opencontainers/runtime-spec/.tool/version-doc.go generated vendored
View file

@ -1,25 +0,0 @@
// +build ignore
package main
import (
"fmt"
"html/template"
"os"
"github.com/opencontainers/runtime-spec/specs-go"
)
var markdownTemplateString = `
**Specification Version:** *{{.}}*
`
var markdownTemplate = template.Must(template.New("markdown").Parse(markdownTemplateString))
func main() {
if err := markdownTemplate.Execute(os.Stdout, specs.Version); err != nil {
fmt.Fprintln(os.Stderr, err)
}
}

24
vendor/github.com/opencontainers/runtime-spec/.travis.yml generated vendored
View file

@ -1,24 +0,0 @@
language: go
go:
- 1.7
- 1.6.3
- 1.5.4
sudo: required
services:
- docker
before_install:
- make install.tools
- docker pull vbatts/pandoc
install: true
script:
- env | grep TRAVIS_
- make .govet
- make .golint
- echo "${TRAVIS_COMMIT_RANGE} -> ${TRAVIS_COMMIT_RANGE/.../..} (travis-ci/travis-ci#4596)"
- TRAVIS_COMMIT_RANGE="${TRAVIS_COMMIT_RANGE/.../..}" make .gitvalidation
- make docs

476
vendor/github.com/opencontainers/runtime-spec/ChangeLog generated vendored
View file

@ -1,476 +0,0 @@
OpenContainers Specifications
Changes with v1.0.0-rc4:
Additions:
* config-linux: Allow negative values for some resources (#648)
* config-linux: Lift no-tweaking namespace restriction (#649)
Removals and increased restrictions:
* config: Rlimit types must be unique (#607)
* config: Forbid empty-string keys in 'annotations' (#645, #654)
* config-linux: Require runtime errors for pre-existing devices
(#647)
* runtime: Only require 'pid' in the state for created/running
statuses (#664)
* schema: Add 'consoleSize' and update requirements (#646)
* schema: Remove string pointers (#656)
* schema/config-linux: Remove blockIODeviceThrottle and other
pointers (#545)
Breaking Go changes:
* specs-go/config: Remove string pointers (#653)
* specs-go/config: Make Spec.Hooks a pointer (#427)
* specs-go/config: Convert some resources from unsigned integers
to signed integers (#648)
Minor fixes and documentation:
* config: Explicitly list 'hooks' as optional and cite POSIX for
'env' and 'args' (#427)
* runtime: Replace "process is stopped" with "process exits"
(#465)
* schema/config-linux: Add missing kernelTCP (#655)
* schema/validate: Allow schema identifiers to contain a URL
scheme (#490)
* .travis: Fix git-validation commit ranges (#216)
* *: Add anchor tags to a number of spec locations (#612, #636,
#637, #638, #639, #640)
* *: Typo fixes and polishing (#643, #650, #652, #656, #660, #665)
Changes with v1.0.0-rc3:
Additions:
* config: Add support for Windows-based containers (#565, #573)
* config: Add process.consoleSize (#563)
* config: Explicitly allow unknown extensions and document
annotations key conventions (#510)
* config: Define mounts entries for Solaris (#588)
Removals and increased restrictions:
* config: Require absolute paths for mount destinations (#609)
* config-linux: Require absolute path for maskedPaths and
readonlyPaths (#587)
* config-linux: Only require /dev/console when process.terminal is
true. Also require /dev/console to be provided by a bind mount
(#518)
* runtime: Require runtimes to generate errors when the container
specified in config.json cannot be created (#559)
Breaking Go changes:
* specs-go/config: Aggressive namespacing (#567)
* specs-go/config: Remove pointers from LinuxHugepageLimit,
LinuxInterfacePriority, and LinuxPids properties (#586)
* specs-go/state: Rename version to ociVersion (#633)
LinuxInterfacePriority, and LinuxPids properties (#586)
Minor fixes and documentation:
* spec: Separate the spec from project scaffolding (#626)
* README: Define "unspecified", "undefined", and
"implementation-defined" (#575)
* config: Clarify absolue and relative values for root.path (#558)
* config: Clarify ociVersion covering the configuration <->
runtime API (#523)
* config-linux: Forbid duplicated namespaces with same `type`
(#597)
* glossary: Make objects explicitly unordered and forbid duplicate
names (#584)
* specs-go/config: Add platform tags to Rlimits and
NoNewPRivileges (#564)
* schema/defs-linux: Use int64 for major/minor types (#610)
* Makefile: Add support for Go 1.7 (#547)
* Makefile: Require Go >= 1.6 for golint (#589)
* Makefile: Use a POSIX-compatible test ('==' -> '=') (#542)
* implementations: Rename ocitools -> runtime-tools (#585)
* *: Typo fixes and polishing (#556, #566, #568, #569, #571, #572,
#574, #595, #596, #599, #600, #601, #603, #605, #608, #613, #617,
#619, #621, #622, #623, #624, #625, #627, #629)
Changes with v1.0.0-rc2:
Additions:
* config-linux: Add new architectures from libseccomp 2.3.0 (#505)
* schema: Add JSON Schema for state JSON and move schema.json to
config-schema.json and similar (#481, #498, #519)
Minor fixes and documentation:
* Add compliance language for platforms and architectures (#527)
* Remove "unconditionally compliant" language (#553)
* bundle: Remove distribution references (#487)
* runtime: Fix sub-bullet indentation (#495)
* config: Replace Arch fstab reference with mount(8) (#443)
* config: Synchronize comments between Markdown and Go (#525)
* config: Drop v0.x compatibility statement (#488)
* config-linux: RFC 2119 wording for cgroupsPath (#493)
* config-linux: Make linux.devices and linux.resources.devices
optional (#526)
* config-linux: Extend no-tweak requirement to runtime namespaces (#538)
* schema: Add hook.timeout (#544)
* schema: Add missing '"type": "object"' (#528)
* schema: Run 'make fmt' and remove duplicates (#546, #551)
* schema/config: Make 'hostname' optional (#491)
* schema/config-linux: Add linux.resources.devices (#550)
* specs-go/config: Add Solaris tags to User properties (#496)
* specs-go/config: Make Linux and Solaris omitempty again (#502)
* specs-go/config: Make KernelTCP and ClassID omitempty (#531)
* specs-go/config: Fix "specified" typo for ApparmorProfile (#503)
* Makefile: Remove code-of-conduct.md and version.md when clean (#541)
* implementations: Mention cc-oci-runtime (#539)
* Use filesystem instead of file system (#529)
* .pullapprove: Add DCO check via PullApprove
* GOVERNANCE: Add governance and release process docs (#521)
* README: Change meeting time from 10am to 2pm Pacific (#524)
* README: Update conference-call phone number (#512, #515)
Changes with v1.0.0-rc1:
Breaking changes:
* runtime: Split create and start, #384, #450, #463, #464, #467,
#468
* runtime: Remove exec, #388
* runtime: Enviroment MUST match the configuration, #397
* config: Runtime MUST generate errors for unsupported platforms,
#441
* config: Windows mount destinations MUST NOT be nested, #437
Additions:
* solaris: Added platform-specific configuration, #411, #424, #431,
#436
* runtime: Add 'annotations' and 'status' to the state structure,
#462, #484, #485
* runtime: State no longer needs to be serialized as JSON, #446
* runtime-linux: Add /dev symbolic links, #449
* config: Allow absolute paths for root.path (which previously
required relative paths), #394
* config-linux: Add linux.mountLabel, #393
* config-linux: Add suport for cgroup namespace, #397
* config-linux: Runtime SHOULD NOT modify ownership of any
referenced filesystem (previously the restriction only applied to
the root filesystem), #452
* specs-go/seccomp: Add ppc and s390x to specs-go/config.go, #475
Minor fixes and documentation:
* README: Add project.md to the Table of Contents, #376
* README: Consistenly indent the Table of Contents, #400
* README: Link to LICENSE, #442
* README: Weekly call is OCI-wide, #378
* config: Explicit runtime namespace for hooks, #415
* config: Explicit container namespace for uid, gid, and
additionalGids, #412
* config: Fix 'string' -> 'array of strings' typo for process.args,
#416
* runtime: The runtime MAY validate config.json, #418
* runtime: Move errors section out of operations, #445
* runtime: MAY -> SHOULD for post-stop error logging, #410
* schema/README: Document JSON Schema usage, #360, #385
* schema: Minor description updates, #456, #461
* schema/validate: Support reading documents via stdin, #482
* .pullapprove: Automate review approval, #458, #474
* .gitignore: Hide more auto-generated files, #386, #392
* .travis: git-validation detects Travis now, #366
* .travis: Regress on failure to produce docs, #479
* Makefile: Filename docs.* -> oci-runtime-spec.*, #478
* Makefile: Add install.tools target, #349
* Makefile: Allow native pandoc implementations, #428, #448
* Makefile: Prefer Bash, #455
* Makefile: Travis support for .gitvalidation, #422
* specs-go/config: Add missing omitempties for Process.Terminal,
Root.Readonly, Spec.Linux, and Spec.Mounts, #408, #429, #430, #431
* specs-go/config: Remove incorrect omitempties for User.UID and
User.GID, #425
* specs-go/config: Drop platform-independent comment, #451
* version: Include version in generated documentation, #406
* *: Anchor examples, #348
* *: Fix remnants from SelinuxProcessLabel to SelinuxLabel rename,
#396
* *: Outsource code-of-conduct to TOB repository, #375, #413
* *: RFC 2119 consistency, #407, #409, #438, #444, #449
* *: Typo fixes, #390, #401
* *: Whitespace fixes and validation, #380, #381, #426
* ROADMAP: Remove stale targets, #435
Changes with v0.5.0:
Breaking changes:
* specs-go: Renamed the repository from opencontainers/specs to
opencontainers/runtime-spec, #365
Additions:
* config: Add 'timeout' for hooks, #346
* config-linux: Add 'maskedPaths' and 'readonlyPaths', #364
Minor fixes and documentation:
* JSON Schema bug-fixes and improved examples, #370
* README: Define "unconditionally compliant", #374
* config: Make Markdown canonical, #342
* config: Explicitly list mapping from symbolic names to UID/GIDs as
out-of-scope, #347
* config-linux: Require the runtime mount namespace for namespace
'path' values, #275
* config-linux: Reword kernelTCP docs, #377
* specs-go: Add omitempty to 'Device' and 'Namespace', #340
* .travis.yml: Use built-in 'go vet' and current 'go lint', dropping
Go < 1.5, #372, #352
* implementations: Expand ocitools scope to include testing, #328
* style: Move one-sentence-per-line rule from the README, #369
* style: Remove dangling parenthesis, #359
* README: Add a link to the IRC logs, #358
* Fix "manadate", "exmaple", "paramters", and "preferrably" typos,
#353, #354
Changes with v0.4.0:
Breaking changes:
* config: Move capabilities, selinuxProcessLabel, apparmorProfile,
and noNewPrivileges from the linux setting to the process setting
and make them optional, renaming selinuxProcessLabel to
selinuxLabel, #329, #330, #339
* runtime: Rename version to ociVerison in the state JSON, #225
* runtime: Remove the directory requirement for storing state, now
that there is a 'state' operation, #225, #334
* go: Shift *.go to specs-go/*.go, #276
* config: Move rlimits to process, #341
* go: Move config_linux.go content into config.go, removing
LinuxSpec, #310
Additions:
* schema: Add JSON Schema (and validator) for `config.json`, #313
* config: Add annotations for opaque-to-the-runtime data, #331
* config-linux: Make seccomp optional, #333
* runtime: Added additional operations: state, stop, and exec.
#225
Minor fixes and documentation:
* config-linux: Change mount type from *rune to *string and fix
octal fileMode examples, #323
* runtime: RFC 2119 phrasing for the lifecycle, #225
* README: Add a full example of config.json, #276
* README: Replace BlueJeans with UberConference, #326, #338
* style: Document Go-pointer exceptions, #317
Changes with v0.3.0:
Breaking changes:
* config: Single, unified config file, #284
* config: cwd is a required default, and must be absolute, #286,
#307, #308, #312
* config: qualify the name of the version field, #309
* config-linux: Convert classID from hex to uint32, #296
* config-linux: Separate mknod from cgroups, #298
Additions:
* config-linux: Add NoNewPrivileges setting for linux, #290
Minor fixes and documentation:
* config-linux: clarify oom_score_adj, #236, #292
* config-linux: Update links to cgroups documentation, #318
* config-linux: Remove pointers for slices preferring omitempty
tag instead, #316
* README: add runtime, bundle, and hook author user, #280
* ROADMAP: reshuffled and split into GitHub issues, #300, #301,
#304, #306
* style: Collect established styles in a discoverable location, #287, #311
Changes with v0.2.0:
* Add Apparmor, Selinux and Seccomp
* Add Apparmor, Selinux and Seccomp sections
* Add bind mount example
* Add fd section for linux container process
* Add Go types for specification
* *: adding a code of conduct
* Adding cgroups path to the Spec.
* .: Adding listing of implementations
* .: adding travis file for future CI
* Add license and DCO information for contributions
* Add linux spec description
* Add MAINTAINERS file
* Add memory swappiness to linux spec
* Add runtime state configuration and structs
* Adds a section for user namespace mappings
* Adds link to kernel cgroups documentation
* Adds section for Linux Rlimits
* Adds section for Linux Sysctl.
* Adds user namespace to the list of namespaces
* bundle: add initial run use case
* bundle: Fix 'and any number of and other related' typo
* bundle.md: clarify arbitrary/conventional dirnames
* bundle.md: fix link formatting
* bundle.md: fix off-by-one error
* bundle.md: various updates to latest spec
* bundle: Move 'Linux sysctl' header to its own line
* Change commiter to committer
* Change Device field order in spec_linux.go, 'Path' should be top of the 'Type' field, according to the different of the config-linux.md, 'Path' field is the unique key.
* Change layout of mountpoints and mounts
* Change the rlimit type to string instead of int
* Clarify behavior around namespaces paths.
* config: Add example additionalGids
* config: Add example cwd
* config: cleanup language on readonly parameter
* config: fix links to go files
* config-linux: specify the default devices/filesystems available
* config.md: clarify destination for mounts
* config.md: make the version a semver
* config.md: make the version field example a semver
* config.md: minor clean up of process specification
* config.md: reformat into a standard style
* config.md: update links to spec schema code
* config.md: various cleanup/consistency fixes
* config: minor cleanup
* Deduplicate the field of RootfsPropagation
* Define constants for Linux Namespace names
* Fix LinuxRuntime field
* Fix root object keys
* Fix typos in config.md
* Fix typos in the "Namespace types" section
* Fix typos in the rlimits section
* Fix Windows path escaping in example mount JSON
* JSON objects are easier to parse/manipulate
* made repo public. Added warning in README
* Make namespaces match runc
* make rootfs mount propagation mode settable
* Makes namespaces description linux specific
* *.md: markdown formatting
* Modify the capabilities constants to match header files like other constants
* Move linux specific options to linux spec
* README: add a rule for paragraph formatting in markdown
* README: Document BlueJeans and wiki archive for meetings
* README: Document pre-meeting agenda alteration
* README: Document YouTube and IRC backchannel for meetings
* README: Focus on local runtime (create/start/stop)
* README.md: Add a git commit style guide
* README.md: contribution about discussion
* README: releases section
* README: Remove blank line from infrastructure-agnostic paragraph
* removed boilerplate file
* *: remove superfluous comma in code-of-conduct
* Remove trailing whitespace
* Rename SystemProperties to Sysctl
* Rename the header "Access to devices" to "Devices" to fit with the config
* *: re-org the spec
* Replace Linux.Device with more specific config
* restore formatting
* Return golang compliant names for UID and GID in User
* Return golint-compliant naming for mappings
* runtime: Add prestart/poststop hooks
* runtime_config: comments for golint
* runtime-config-linux: Drop 'Linux' from headers
* runtime_config_linux: Fix 'LinuxSpec' -> 'LinuxRuntimeSpec' in comment
* runtime-config-linux: One sentence per line for opening two paragraphs
* runtime-config: Remove blank lines from the end of files
* runtime-config: Remove 'destination' docs from mounts
* runtime.md: convert oc to runc
* runtime: use opencontainer vs oci
* *: small spelling fixes
* Specific platform specific user struct for spec
* spec: linux: add support for the PIDs cgroup
* spec_linux: conform to `golint`
* spec_linux.go: Rename IDMapping fields to follow syscall.SysProcIDMap
* spec_linux: remove ending periods on one-line comments
* spec: rename ocp to oci and add a link
* specs: add json notation
* specs: align the ascii graph
* specs: fix the description for the [ug]idMappings
* specs: introduce the concept of a runtime.json
* .tools: cleanup the commit entry
* .tools: repo validation tool
* travis: fix DCO validation for merges
* typo: containers -> container's
* typo: the -> for
* Update config-linux for better formatting on values
* Update README.md
* Update readme with weekly call and mailing list
* Update runtime.md
* Update runtime.md
* Update runtime.md
* version: more explicit version for comparison
Changes with v0.1.0:
* Add Architecture field to Seccomp configuration in Linux runtime
* Add @hqhq as maintainer
* Add hyphen for host specific
* Adding Vishnu Kannan as a Maintainer.
* Add initial roadmap
* Add lifecycle for containers
* Add oom_score_adj to the runtime Spec.
* Add post-start hooks
* Add Seccomp constants to description of Linux runtime spec
* Add Seccomp constants to Linux runtime config
* Add some clarity around the state.json file
* adds text describing the upper-case keywords used in the spec
* add testing framework to ROADMAP
* Appropriately mark optional fields as omitempty
* cgroup: Add support for memory.kmem.tcp.limit_in_bytes
* Change HugepageLimit.Limit type to uint64
* Change the behavior when cgroupsPath is absent
* Change version from 0.1.0 to 0.2.0
* Clarify the semantics of hook elements
* Cleanup bundle.md
* Cleanup principles
* config: linux: update description of PidsLimit
* config: Require a new UTS namespace for config.json's hostname
* config: Require the runtime to mount Spec.Mounts in order
* convert **name** to **`name`**
* Example lists "root' but text mentions "bundlePath"
* Fix an extra space in VersionMinor
* Fix golint warnings
* Fix typo in BlockIO struct comment
* Fix typo in Filesystem Bundle
* Fix value of swappiness
* glossary: Provide a quick overview of important terms
* glossary: Specify UTF-8 for all our JSON
* hooks: deduplicate the hooks docs
* implementations: Link to kunalkushwaha/octool
* implementations: Link to mrunalp/ocitools
* lifecycle: Don't require /run/opencontainer/<runtime>/containers
* lifecycle: Mention runtime.json
* lifecycle: no hypens
* MAINTAINERS: add tianon per the charter
* MAINTAINERS: correct Vish's github account
* Makefile: Add glossary to DOC_FILES
* Make optional Cgroup related config params pointers along with `omitempty` json tag.
* Mark RootfsPropagation as omitempty
* *.md: update TOC and links
* move the description of Rlimits before example
* move the description of user ns mapping to proper file
* principles: Give principles their own home
* *: printable documents
* Project: document release process
* README: Fix some headers
* README: make header more concise
* remove blank char from blank line
* Remove the unneeded build tag from the config_linux.go
* Remove trailing comma in hooks json example
* Rename State's Root to Bundle
* ROADMAP.md: remove the tail spaces
* roadmap: update links and add wiki reference
* runtime: Add 'version' to the state.json example
* runtime-config: add example label before json example
* runtime-config: add section about Hooks
* runtime: config: linux: add cgroups information
* runtime: config: linux: Edit BlockIO struct
* runtime: config: linux: Fix typo and trailing commas in json example
* runtime_config_linux.go: add missing pointer
* runtime-config-linux.md: fix the type of cpus and mems
* runtime.md: fix spacing
* Talk about host specific/independent instead of mutability
* .tools: commit validator is a separate project
* .tools: make GetFetchHeadCommit do what it says
* .travis.yml: add go 1.5.1, update from 1.4.2 to 1.4.3
* Update readme with wiki link to minutes
* Update Typo in ROADMAP.md
* Use unsigned for IDs
* version: introduce a string for dev indication

70
vendor/github.com/opencontainers/runtime-spec/GOVERNANCE.md generated vendored
View file

@ -1,70 +0,0 @@
# Project governance
The [OCI charter][charter] §5.b.viii tasks an OCI Project's maintainers (listed in the repository's MAINTAINERS file and sometimes referred to as "the TDC", [§5.e][charter]) with:
> Creating, maintaining and enforcing governance guidelines for the TDC, approved by the maintainers, and which shall be posted visibly for the TDC.
This section describes generic rules and procedures for fulfilling that mandate.
## Proposing a motion
A maintainer SHOULD propose a motion on the dev@opencontainers.org mailing list (except [security issues](#security-issues)) with another maintainer as a co-sponsor.
## Voting
Voting on a proposed motion SHOULD happen on the dev@opencontainers.org mailing list (except [security issues](#security-issues)) with maintainers posting LGTM or REJECT.
Maintainers MAY also explicitly not vote by posting ABSTAIN (which is useful to revert a previous vote).
Maintainers MAY post multiple times (e.g. as they revise their position based on feeback), but only their final post counts in the tally.
A proposed motion is adopted if two-thirds of votes cast, a quorum having voted, are in favor of the release.
Voting SHOULD remain open for a week to collect feedback from the wider community and allow the maintainers to digest the proposed motion.
Under exceptional conditions (e.g. non-major security fix releases) proposals which reach quorum with unanimous support MAY be adopted earlier.
A maintainer MAY choose to reply with REJECT.
A maintainer posting a REJECT MUST include a list of concerns or links to written documentation for those concerns (e.g. GitHub issues or mailing-list threads).
The maintainers SHOULD try to resolve the concerns and wait for the rejecting maintainer to change their opinion to LGTM.
However, a motion MAY be adopted with REJECTs, as outlined in the previous paragraphs.
## Quorum
A quorum is established when at least two-thirds of maintainers have voted.
For projects that are not specifications, a [motion to release](#release-approval) MAY be adopted if the tally is at least three LGTMs and no REJECTs, even if three votes does not meet the usual two-thirds quorum.
## Security issues
Motions with sensitive security implications MUST be proposed on the security@opencontainers.org mailing list instead of dev@opencontainers.org, but should otherwise follow the standard [proposal](#proposing-a-motion) process.
The security@opencontainers.org mailing list includes all members of the TOB.
The TOB will contact the project maintainers and provide a channel for discussing and voting on the motion, but voting will otherwise follow the standard [voting](#voting) and [quorum](#quorum) rules.
The TOB and project maintainers will work together to notify affected parties before making an adopted motion public.
## Amendments
The [project governance](#project-governance) rules and procedures MAY be amended or replaced using the procedures themselves.
The MAINTAINERS of this project governance document is the total set of MAINTAINERS from all Open Containers projects (runC, runtime-spec, and image-spec).
## Subject templates
Maintainers are busy and get lots of email.
To make project proposals recognizable, proposed motions SHOULD use the following subject templates.
### Proposing a motion
> [{project} VOTE]: {motion description} (closes {end of voting window})
For example:
> [runtime-spec VOTE]: Tag 0647920 as 1.0.0-rc (closes 2016-06-03 20:00 UTC)
### Tallying results
After voting closes, a maintainer SHOULD post a tally to the motion thread with a subject template like:
> [{project} {status}]: {motion description} (+{LGTMs} -{REJECTs} #{ABSTAINs})
Where `{status}` is either `adopted` or `rejected`.
For example:
> [runtime-spec adopted]: Tag 0647920 as 1.0.0-rc (+6 -0 #3)
[charter]: https://www.opencontainers.org/about/governance

9
vendor/github.com/opencontainers/runtime-spec/MAINTAINERS generated vendored
View file

@ -1,9 +0,0 @@
Michael Crosby <michael@docker.com> (@crosbymichael)
Alexander Morozov <lk4d4@docker.com> (@LK4D4)
Vishnu Kannan <vishnuk@google.com> (@vishh)
Mrunal Patel <mpatel@redhat.com> (@mrunalp)
Vincent Batts <vbatts@redhat.com> (@vbatts)
Daniel, Dao Quang Minh <dqminh89@gmail.com> (@dqminh)
Brandon Philips <brandon.philips@coreos.com> (@philips)
Tianon Gravi <admwiggin@gmail.com> (@tianon)
Qiang Huang <h.huangqiang@huawei.com> (@hqhq)

101
vendor/github.com/opencontainers/runtime-spec/Makefile generated vendored
View file

@ -1,101 +0,0 @@
EPOCH_TEST_COMMIT := 78e6667ae2d67aad100b28ee9580b41b7a24e667
OUTPUT_DIRNAME ?= output
DOC_FILENAME ?= oci-runtime-spec
DOCKER ?= $(shell command -v docker 2>/dev/null)
PANDOC ?= $(shell command -v pandoc 2>/dev/null)
ifeq "$(strip $(PANDOC))" ''
ifneq "$(strip $(DOCKER))" ''
PANDOC = $(DOCKER) run \
-it \
--rm \
-v $(shell pwd)/:/input/:ro \
-v $(shell pwd)/$(OUTPUT_DIRNAME)/:/$(OUTPUT_DIRNAME)/ \
-u $(shell id -u) \
vbatts/pandoc
PANDOC_SRC := /input/
PANDOC_DST := /
endif
endif
# These docs are in an order that determines how they show up in the PDF/HTML docs.
DOC_FILES := \
version.md \
spec.md \
principles.md \
bundle.md \
runtime.md \
runtime-linux.md \
config.md \
config-linux.md \
config-solaris.md \
glossary.md
default: docs
.PHONY: docs
docs: $(OUTPUT_DIRNAME)/$(DOC_FILENAME).pdf $(OUTPUT_DIRNAME)/$(DOC_FILENAME).html
ifeq "$(strip $(PANDOC))" ''
$(OUTPUT_DIRNAME)/$(DOC_FILENAME).pdf $(OUTPUT_DIRNAME)/$(DOC_FILENAME).html:
$(error cannot build $@ without either pandoc or docker)
else
$(OUTPUT_DIRNAME)/$(DOC_FILENAME).pdf: $(DOC_FILES)
mkdir -p $(OUTPUT_DIRNAME)/ && \
$(PANDOC) -f markdown_github -t latex -o $(PANDOC_DST)$@ $(patsubst %,$(PANDOC_SRC)%,$(DOC_FILES))
$(OUTPUT_DIRNAME)/$(DOC_FILENAME).html: $(DOC_FILES)
mkdir -p $(OUTPUT_DIRNAME)/ && \
$(PANDOC) -f markdown_github -t html5 -o $(PANDOC_DST)$@ $(patsubst %,$(PANDOC_SRC)%,$(DOC_FILES))
endif
version.md: ./specs-go/version.go
go run ./.tool/version-doc.go > $@
HOST_GOLANG_VERSION = $(shell go version | cut -d ' ' -f3 | cut -c 3-)
# this variable is used like a function. First arg is the minimum version, Second arg is the version to be checked.
ALLOWED_GO_VERSION = $(shell test '$(shell /bin/echo -e "$(1)\n$(2)" | sort -V | head -n1)' = '$(1)' && echo 'true')
.PHONY: test .govet .golint .gitvalidation
test: .govet .golint .gitvalidation
.govet:
go vet -x ./...
# `go get github.com/golang/lint/golint`
.golint:
ifeq ($(call ALLOWED_GO_VERSION,1.6,$(HOST_GOLANG_VERSION)),true)
@which golint > /dev/null 2>/dev/null || (echo "ERROR: golint not found. Consider 'make install.tools' target" && false)
golint ./...
endif
# When this is running in travis, it will only check the travis commit range
.gitvalidation:
@which git-validation > /dev/null 2>/dev/null || (echo "ERROR: git-validation not found. Consider 'make install.tools' target" && false)
ifdef TRAVIS_COMMIT_RANGE
git-validation -q -run DCO,short-subject,dangling-whitespace
else
git-validation -v -run DCO,short-subject,dangling-whitespace -range $(EPOCH_TEST_COMMIT)..HEAD
endif
.PHONY: install.tools
install.tools: .install.golint .install.gitvalidation
# golint does not even build for <go1.6
.install.golint:
ifeq ($(call ALLOWED_GO_VERSION,1.6,$(HOST_GOLANG_VERSION)),true)
go get -u github.com/golang/lint/golint
endif
.install.gitvalidation:
go get -u github.com/vbatts/git-validation
.PHONY: clean
clean:
rm -rf $(OUTPUT_DIRNAME) *~
rm -f version.md

51
vendor/github.com/opencontainers/runtime-spec/RELEASES.md generated vendored
View file

@ -1,51 +0,0 @@
# Releases
The release process hopes to encourage early, consistent consensus-building during project development.
The mechanisms used are regular community communication on the mailing list about progress, scheduled meetings for issue resolution and release triage, and regularly paced and communicated releases.
Releases are proposed and adopted or rejected using the usual [project governance](GOVERNANCE.md) rules and procedures.
An anti-pattern that we want to avoid is heavy development or discussions "late cycle" around major releases.
We want to build a community that is involved and communicates consistently through all releases instead of relying on "silent periods" as a judge of stability.
## Parallel releases
A single project MAY consider several motions to release in parallel.
However each motion to release after the initial 0.1.0 MUST be based on a previous release that has already landed.
For example, runtime-spec maintainers may propose a v1.0.0-rc2 on the 1st of the month and a v0.9.1 bugfix on the 2nd of the month.
They may not propose a v1.0.0-rc3 until the v1.0.0-rc2 is accepted (on the 7th if the vote initiated on the 1st passes).
## Specifications
The OCI maintains three categories of projects: specifications, applications, and conformance-testing tools.
However, specification releases have special restrictions in the [OCI charter][charter]:
* They are the target of backwards compatibility (§7.g), and
* They are subject to the OFWa patent grant (§8.d and e).
To avoid unfortunate side effects (onerous backwards compatibity requirements or Member resignations), the following additional procedures apply to specification releases:
### Planning a release
Every OCI specification project SHOULD hold meetings that involve maintainers reviewing pull requests, debating outstanding issues, and planning releases.
This meeting MUST be advertised on the project README and MAY happen on a phone call, video conference, or on IRC.
Maintainers MUST send updates to the dev@opencontainers.org with results of these meetings.
Before the specification reaches v1.0.0, the meetings SHOULD be weekly.
Once a specification has reached v1.0.0, the maintainers may alter the cadence, but a meeting MUST be held within four weeks of the previous meeting.
The release plans, corresponding milestones and estimated due dates MUST be published on GitHub (e.g. https://github.com/opencontainers/runtime-spec/milestones).
GitHub milestones and issues are only used for community organization and all releases MUST follow the [project governance](GOVERNANCE.md) rules and procedures.
### Timelines
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.
- Minor and patch releases SHOULD be made on an as-needed basis.
[charter]: https://www.opencontainers.org/about/governance

50
vendor/github.com/opencontainers/runtime-spec/ROADMAP.md generated vendored
View file

@ -1,50 +0,0 @@
# OCI Specs Roadmap
This document serves to provide a long term roadmap on our quest to a 1.0 version of the OCI container specification.
Its goal is to help both maintainers and contributors find meaningful tasks to focus on and create a low noise environment.
The items in the 1.0 roadmap can be broken down into smaller milestones that are easy to accomplish.
The topics below are broad and small working groups will be needed for each to define scope and requirements or if the feature is required at all for the OCI level.
Topics listed in the roadmap do not mean that they will be implemented or added but are areas that need discussion to see if they fit in to the goals of the OCI.
Listed topics may defer to the [project wiki][runtime-wiki] for collaboration.
## 1.0
### Container Definition
Define what a software container is and its attributes in a cross platform way.
Could be solved by lifecycle/ops and create/start split discussions
*Owner:* vishh & duglin
### Version Schema
Decide on a robust versioning schema for the spec as it evolves.
Resolved but release process could evolve. Resolved for v0.2.0, expect to revisit near v1.0.0
*Owner:* vbatts
### Base Config Compatibility
Ensure that the base configuration format is viable for various platforms.
Systems:
* Linux
* Solaris
* Windows
*Owner:* robdolinms as lead coordinator
### Full Lifecycle Hooks
Ensure that we have lifecycle hooks in the correct places with full coverage over the container lifecycle.
Will probably go away with Vish's work on splitting create and start, and if we have exec.
*Owner:*
[runtime-wiki]: https://github.com/opencontainers/runtime-spec/wiki/RoadMap

24
vendor/github.com/opencontainers/runtime-spec/bundle.md generated vendored
View file

@ -1,24 +0,0 @@
# <a name="filesystemBundle" />Filesystem Bundle
## <a name="containerFormat" />Container Format
This section defines a format for encoding a container as a *filesystem bundle* - a set of files organized in a certain way, and containing all the necessary data and metadata for any compliant runtime to perform all standard operations against it.
See also [MacOS application bundles][macos_bundle] for a similar use of the term *bundle*.
The definition of a bundle is only concerned with how a container, and its configuration data, are stored on a local filesystem so that it can be consumed by a compliant runtime.
A Standard Container bundle contains all the information needed to load and run a container.
This MUST include 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.
2. <a name="containerFormat02" />A directory representing the root filesystem of the container.
While the name of this REQUIRED directory may be arbitrary, users should consider using a conventional name, such as `rootfs`.
This directory MUST be referenced from within the `config.json` file.
While these artifacts MUST all be present in a single directory on the local filesystem, that directory itself is not part of the bundle.
In other words, a tar archive of a *bundle* will have these artifacts at the root of the archive, not nested within a top-level directory.
[macos_bundle]: https://en.wikipedia.org/wiki/Bundle_%28macOS%29

641
vendor/github.com/opencontainers/runtime-spec/config-linux.md generated vendored
View file

@ -1,641 +0,0 @@
# <a name="linuxContainerConfiguration" />Linux Container Configuration
This document describes the schema for the [Linux-specific section](config.md#platform-specific-configuration) of the [container configuration](config.md).
The Linux container specification uses various kernel features like namespaces, cgroups, capabilities, LSM, and filesystem jails to fulfill the spec.
## <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.
The following filesystems SHOULD be made available in each container's filesystem:
| Path | Type |
| -------- | ------ |
| /proc | [procfs][procfs] |
| /sys | [sysfs][sysfs] |
| /dev/pts | [devpts][devpts] |
| /dev/shm | [tmpfs][tmpfs] |
## <a name="configLinuxNamespaces" />Namespaces
A namespace wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated 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 [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:
* **`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.
* **`network`** the container will have its own network stack.
* **`mount`** the container will have an isolated mount table.
* **`ipc`** processes inside the container will only be able to communicate to other processes inside the same container via system level IPC.
* **`uts`** the container will be able to have its own hostname and domain name.
* **`user`** the container will be able to remap user and group IDs from the host to local users and groups within the container.
* **`cgroup`** the container will have an isolated view of the cgroup hierarchy.
* **`path`** *(string, OPTIONAL)* - path to namespace file in the [runtime mount namespace](glossary.md#runtime-namespace)
If a path is specified, that particular file is used to join that type of namespace.
If a namespace type is not specified in the `namespaces` array, the container MUST inherit the [runtime namespace](glossary.md#runtime-namespace) of that type.
If a `namespaces` field contains duplicated namespaces with same `type`, the runtime MUST error out.
###### Example
```json
"namespaces": [
{
"type": "pid",
"path": "/proc/1234/ns/pid"
},
{
"type": "network",
"path": "/var/run/netns/neta"
},
{
"type": "mount"
},
{
"type": "ipc"
},
{
"type": "uts"
},
{
"type": "user"
},
{
"type": "cgroup"
}
]
```
## <a name="configLinuxUserNamespaceMappings" />User namespace mappings
**`uidMappings`** (array of objects, OPTIONAL) describes the user namespace uid mappings from the host to the container.
**`gidMappings`** (array of objects, OPTIONAL) describes the user namespace gid mappings from the host to the container.
Each entry has the following structure:
* **`hostID`** *(uint32, REQUIRED)* - is the starting uid/gid on the host to be mapped to *containerID*.
* **`containerID`** *(uint32, REQUIRED)* - is the starting uid/gid in the container.
* **`size`** *(uint32, REQUIRED)* - is the number of ids to be mapped.
The runtime SHOULD NOT modify the ownership of referenced filesystems to realize the mapping.
Note that the number of mapping entries MAY be limited by the [kernel][user-namespaces].
###### Example
```json
"uidMappings": [
{
"hostID": 1000,
"containerID": 0,
"size": 32000
}
],
"gidMappings": [
{
"hostID": 1000,
"containerID": 0,
"size": 32000
}
]
```
## <a name="configLinuxDevices" />Devices
**`devices`** (array of objects, OPTIONAL) lists devices that MUST be available in the container.
The runtime may supply them however it likes (with [mknod][mknod.2], by bind mounting from the runtime mount namespace, etc.).
Each entry has the following structure:
* **`type`** *(string, REQUIRED)* - type of device: `c`, `b`, `u` or `p`.
More info in [mknod(1)][mknod.1].
* **`path`** *(string, REQUIRED)* - full path to device inside container.
If a [file][file.1] 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).
* **`uid`** *(uint32, OPTIONAL)* - id of device owner.
* **`gid`** *(uint32, OPTIONAL)* - id of device group.
The same `type`, `major` and `minor` SHOULD NOT be used for multiple devices.
###### Example
```json
"devices": [
{
"path": "/dev/fuse",
"type": "c",
"major": 10,
"minor": 229,
"fileMode": 438,
"uid": 0,
"gid": 0
},
{
"path": "/dev/sda",
"type": "b",
"major": 8,
"minor": 0,
"fileMode": 432,
"uid": 0,
"gid": 0
}
]
```
###### <a name="configLinuxDefaultDevices" />Default Devices
In addition to any devices configured with this setting, the runtime MUST also supply:
* [`/dev/null`][null.4]
* [`/dev/zero`][zero.4]
* [`/dev/full`][full.4]
* [`/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/ptmx`][pts.4].
A [bind-mount or symlink of the container's `/dev/pts/ptmx`][devpts].
## <a name="configLinuxControlGroups" />Control groups
Also known as cgroups, they are used to restrict resource usage for a container and handle device access.
cgroups provide controls (through controllers) to restrict cpu, memory, IO, pids and network for the container.
For more information, see the [kernel cgroups documentation][cgroup-v1].
The path to the cgroups can be specified in the Spec via `cgroupsPath`.
`cgroupsPath` can be used to either control the cgroup hierarchy for containers or to run a new process in an existing container.
If `cgroupsPath` is:
* ... an absolute path (starting with `/`), the runtime MUST take the path to be relative to the cgroup mount point.
* ... a relative path (not starting with `/`), the runtime MAY interpret the path relative to a runtime-determined location in the cgroup hierarchy.
* ... not specified, the runtime MAY define the default cgroup path.
Runtimes MAY consider certain `cgroupsPath` values to be invalid, and MUST generate an error if this is the case.
If a `cgroupsPath` value is specified, the runtime MUST consistently attach to the same place in the cgroup hierarchy given the same value of `cgroupsPath`.
Implementations of the Spec can choose to name cgroups in any manner.
The Spec does not include naming schema for cgroups.
The Spec does not support per-controller paths for the reasons discussed in the [cgroupv2 documentation][cgroup-v2].
The cgroups will be created if they don't exist.
You can configure a container's cgroups via the `resources` field of the Linux configuration.
Do not specify `resources` unless limits have to be updated.
For example, to run a new process in an existing container without updating limits, `resources` need not be specified.
A runtime MUST at least use the minimum set of cgroup controllers required to fulfill the `resources` settings.
However, a runtime MAY attach the container process to additional cgroup controllers supported by the system.
###### Example
```json
"cgroupsPath": "/myRuntime/myContainer",
"resources": {
"memory": {
"limit": 100000,
"reservation": 200000
},
"devices": [
{
"allow": false,
"access": "rwm"
}
]
}
```
#### <a name="configLinuxDeviceWhitelist" />Device whitelist
**`devices`** (array of objects, OPTIONAL) configures the [device whitelist][cgroup-v1-devices].
The runtime MUST apply entries in the listed order.
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).
`null` or unset values mean "all", mapping to `a`.
* **`major, minor`** *(int64, OPTIONAL)* - [major, minor numbers][devices] for the device.
`null` or 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).
###### Example
```json
"devices": [
{
"allow": false,
"access": "rwm"
},
{
"allow": true,
"type": "c",
"major": 10,
"minor": 229,
"access": "rw"
},
{
"allow": true,
"type": "b",
"major": 8,
"minor": 0,
"access": "r"
}
]
```
#### <a name="configLinuxDisableOutOfMemoryKiller" />Disable out-of-memory killer
`disableOOMKiller` contains a boolean (`true` or `false`) that enables or disables the Out of Memory killer for a cgroup.
If enabled (`false`), tasks that attempt to consume more memory than they are allowed are immediately killed by the OOM killer.
The OOM killer is enabled by default in every cgroup using the `memory` subsystem.
To disable it, specify a value of `true`.
For more information, see [the memory cgroup man page][cgroup-v1-memory].
* **`disableOOMKiller`** *(bool, OPTIONAL)* - enables or disables the OOM killer
###### Example
```json
"disableOOMKiller": false
```
#### <a name="configLinuxSetOomScoreAdj" />Set oom_score_adj
`oomScoreAdj` sets heuristic regarding how the process is evaluated by the kernel during memory pressure.
For more information, see [the proc filesystem documentation section 3.1][procfs].
This is a kernel/system level setting, where as `disableOOMKiller` is scoped for a memory cgroup.
For more information on how these two settings work together, see [the memory cgroup documentation section 10. OOM Contol][cgroup-v1-memory].
* **`oomScoreAdj`** *(int, OPTIONAL)* - adjust the oom-killer score
###### Example
```json
"oomScoreAdj": 100
```
#### <a name="configLinuxMemory" />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:
* **`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
```json
"memory": {
"limit": 536870912,
"reservation": 536870912,
"swap": 536870912,
"kernel": 0,
"kernelTCP": 0,
"swappiness": 0
}
```
#### <a name="configLinuxCPU" />CPU
**`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:
* **`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
```json
"cpu": {
"shares": 1024,
"quota": 1000000,
"period": 500000,
"realtimeRuntime": 950000,
"realtimePeriod": 1000000,
"cpus": "2-3",
"mems": "0-7"
}
```
#### <a name="configLinuxBlockIO" />Block IO
**`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:
* **`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. The range is from 10 to 1000.
* **`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. The range is from 10 to 1000.
* **`blkioWeightDevice`** *(array, 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 `man mknod`.
* **`weight`** *(uint16, OPTIONAL)* - bandwidth rate for the device, range is from 10 to 1000
* **`leafWeight`** *(uint16, OPTIONAL)* - bandwidth rate for the device while competing with the cgroup's child cgroups, range is from 10 to 1000, CFQ scheduler only
You must specify at least one of `weight` or `leafWeight` in a given entry, and can specify both.
* **`blkioThrottleReadBpsDevice`**, **`blkioThrottleWriteBpsDevice`**, **`blkioThrottleReadIOPSDevice`**, **`blkioThrottleWriteIOPSDevice`** *(array, OPTIONAL)* - specify the list of devices which will be IO rate limited.
The following parameters can be specified per-device:
* **`major, minor`** *(int64, REQUIRED)* - major, minor numbers for device. More info in `man mknod`.
* **`rate`** *(uint64, REQUIRED)* - IO rate limit for the device
###### Example
```json
"blockIO": {
"blkioWeight": 10,
"blkioLeafWeight": 10,
"blkioWeightDevice": [
{
"major": 8,
"minor": 0,
"weight": 500,
"leafWeight": 300
},
{
"major": 8,
"minor": 16,
"weight": 500
}
],
"blkioThrottleReadBpsDevice": [
{
"major": 8,
"minor": 0,
"rate": 600
}
],
"blkioThrottleWriteIOPSDevice": [
{
"major": 8,
"minor": 16,
"rate": 300
}
]
}
```
#### <a name="configLinuxHugePageLimits" />Huge page limits
**`hugepageLimits`** (array of objects, OPTIONAL) represents the `hugetlb` controller which allows to limit the
HugeTLB usage per control group and enforces the controller limit during page fault.
For more information, see the [kernel cgroups documentation about HugeTLB][cgroup-v1-hugetlb].
Each entry has the following structure:
* **`pageSize`** *(string, REQUIRED)* - hugepage size
* **`limit`** *(uint64, REQUIRED)* - limit in bytes of *hugepagesize* HugeTLB usage
###### Example
```json
"hugepageLimits": [
{
"pageSize": "2MB",
"limit": 209715200
}
]
```
#### <a name="configLinuxNetwork" />Network
**`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:
* **`classID`** *(uint32, OPTIONAL)* - is the network class identifier the cgroup's network packets will be tagged with
* **`priorities`** *(array, 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:
* **`name`** *(string, REQUIRED)* - interface name
* **`priority`** *(uint32, REQUIRED)* - priority applied to the interface
###### Example
```json
"network": {
"classID": 1048577,
"priorities": [
{
"name": "eth0",
"priority": 500
},
{
"name": "eth1",
"priority": 1000
}
]
}
```
#### <a name="configLinuxPIDS" />PIDs
**`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:
* **`limit`** *(int64, REQUIRED)* - specifies the maximum number of tasks in the cgroup
###### Example
```json
"pids": {
"limit": 32771
}
```
## <a name="configLinuxSysctl" />Sysctl
**`sysctl`** (object, OPTIONAL) allows kernel parameters to be modified at runtime for the container.
For more information, see the [sysctl(8)][sysctl.8] man page.
###### Example
```json
"sysctl": {
"net.ipv4.ip_forward": "1",
"net.core.somaxconn": "256"
}
```
## <a name="configLinuxSeccomp" />Seccomp
Seccomp provides application sandboxing mechanism in the Linux kernel.
Seccomp configuration allows one to configure actions to take for matched syscalls and furthermore also allows matching on values passed as arguments to syscalls.
For more information about Seccomp, see [Seccomp][seccomp] kernel documentation.
The actions, architectures, and operators are strings that match the definitions in seccomp.h from [libseccomp][] and are translated to corresponding values.
A valid list of constants as of libseccomp v2.3.2 is shown below.
Architecture Constants
* `SCMP_ARCH_X86`
* `SCMP_ARCH_X86_64`
* `SCMP_ARCH_X32`
* `SCMP_ARCH_ARM`
* `SCMP_ARCH_AARCH64`
* `SCMP_ARCH_MIPS`
* `SCMP_ARCH_MIPS64`
* `SCMP_ARCH_MIPS64N32`
* `SCMP_ARCH_MIPSEL`
* `SCMP_ARCH_MIPSEL64`
* `SCMP_ARCH_MIPSEL64N32`
* `SCMP_ARCH_PPC`
* `SCMP_ARCH_PPC64`
* `SCMP_ARCH_PPC64LE`
* `SCMP_ARCH_S390`
* `SCMP_ARCH_S390X`
* `SCMP_ARCH_PARISC`
* `SCMP_ARCH_PARISC64`
Action Constants:
* `SCMP_ACT_KILL`
* `SCMP_ACT_TRAP`
* `SCMP_ACT_ERRNO`
* `SCMP_ACT_TRACE`
* `SCMP_ACT_ALLOW`
Operator Constants:
* `SCMP_CMP_NE`
* `SCMP_CMP_LT`
* `SCMP_CMP_LE`
* `SCMP_CMP_EQ`
* `SCMP_CMP_GE`
* `SCMP_CMP_GT`
* `SCMP_CMP_MASKED_EQ`
###### Example
```json
"seccomp": {
"defaultAction": "SCMP_ACT_ALLOW",
"architectures": [
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"getcwd",
"chmod"
],
"action": "SCMP_ACT_ERRNO",
"comment": "stop exploit x"
}
]
}
```
## <a name="configLinuxRootfsMountPropagation" />Rootfs Mount Propagation
**`rootfsPropagation`** (string, OPTIONAL) sets the rootfs's mount propagation.
Its value is either slave, private, or shared.
The [Shared Subtrees][sharedsubtree] article in the kernel documentation has more information about mount propagation.
###### Example
```json
"rootfsPropagation": "slave",
```
## <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][container-namespace2].
###### Example
```json
"maskedPaths": [
"/proc/kcore"
]
```
## <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][container-namespace2].
###### Example
```json
"readonlyPaths": [
"/proc/sys"
]
```
## <a name"configLinuxMountLabel" />Mount Label
**`mountLabel`** (string, OPTIONAL) will set the Selinux context for the mounts in the container.
###### Example
```json
"mountLabel": "system_u:object_r:svirt_sandbox_file_t:s0:c715,c811"
```
[container-namespace2]: glossary.md#container_namespace
[cgroup-v1]: https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
[cgroup-v1-blkio]: https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt
[cgroup-v1-cpusets]: https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt
[cgroup-v1-devices]: https://www.kernel.org/doc/Documentation/cgroup-v1/devices.txt
[cgroup-v1-hugetlb]: https://www.kernel.org/doc/Documentation/cgroup-v1/hugetlb.txt
[cgroup-v1-memory]: https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
[cgroup-v1-net-cls]: https://www.kernel.org/doc/Documentation/cgroup-v1/net_cls.txt
[cgroup-v1-net-prio]: https://www.kernel.org/doc/Documentation/cgroup-v1/net_prio.txt
[cgroup-v1-pids]: https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
[cgroup-v2]: https://www.kernel.org/doc/Documentation/cgroup-v2.txt
[devices]: https://www.kernel.org/doc/Documentation/devices.txt
[devpts]: https://www.kernel.org/doc/Documentation/filesystems/devpts.txt
[file]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_164
[libseccomp]: https://github.com/seccomp/libseccomp
[procfs]: https://www.kernel.org/doc/Documentation/filesystems/proc.txt
[seccomp]: https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt
[sharedsubtree]: https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt
[sysfs]: https://www.kernel.org/doc/Documentation/filesystems/sysfs.txt
[tmpfs]: https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt
[console.4]: http://man7.org/linux/man-pages/man4/console.4.html
[full.4]: http://man7.org/linux/man-pages/man4/full.4.html
[mknod.1]: http://man7.org/linux/man-pages/man1/mknod.1.html
[mknod.2]: http://man7.org/linux/man-pages/man2/mknod.2.html
[namespaces.7_2]: http://man7.org/linux/man-pages/man7/namespaces.7.html
[null.4]: http://man7.org/linux/man-pages/man4/null.4.html
[pts.4]: http://man7.org/linux/man-pages/man4/pts.4.html
[random.4]: http://man7.org/linux/man-pages/man4/random.4.html
[sysctl.8]: http://man7.org/linux/man-pages/man8/sysctl.8.html
[tty.4]: http://man7.org/linux/man-pages/man4/tty.4.html
[zero.4]: http://man7.org/linux/man-pages/man4/zero.4.html
[user-namespaces]: http://man7.org/linux/man-pages/man7/user_namespaces.7.html

120
vendor/github.com/opencontainers/runtime-spec/config-solaris.md generated vendored
View file

@ -1,120 +0,0 @@
# <a name="solarisApplicationContainerConfiguration" />Solaris Application Container Configuration
Solaris application containers can be configured using the following properties, all of the below properties have mappings to properties specified under [zonecfg(1M)][zonecfg.1m_2] man page, except milestone.
## <a name="configSolarisMilestone" />milestone
The SMF(Service Management Facility) FMRI which should go to "online" state before we start the desired process within the container.
**`milestone`** *(string, OPTIONAL)*
### Example
```json
"milestone": "svc:/milestone/container:default"
```
## <a name="configSolarisLimitpriv" />limitpriv
The maximum set of privileges any process in this container can obtain.
The property should consist of a comma-separated privilege set specification as described in [priv_str_to_set(3C)][priv-str-to-set.3c] man page for the respective release of Solaris.
**`limitpriv`** *(string, OPTIONAL)*
### Example
```json
"limitpriv": "default"
```
## <a name="configSolarisMaxShmMemory" />maxShmMemory
The maximum amount of shared memory allowed for this application container.
A scale (K, M, G, T) can be applied to the value for each of these numbers (for example, 1M is one megabyte).
Mapped to `max-shm-memory` in [zonecfg(1M)][zonecfg.1m] man page.
**`maxShmMemory`** *(string, OPTIONAL)*
### Example
```json
"maxShmMemory": "512m"
```
## <a name="configSolarisCappedCpu" />cappedCPU
Sets a limit on the amount of CPU time that can be used by a container.
The unit used translates to the percentage of a single CPU that can be used by all user threads in a container, expressed as a fraction (for example, .75) or a mixed number (whole number and fraction, for example, 1.25).
An ncpu value of 1 means 100% of a CPU, a value of 1.25 means 125%, .75 mean 75%, and so forth.
When projects within a capped container have their own caps, the minimum value takes precedence.
cappedCPU is mapped to `capped-cpu` in [zonecfg(1M)][zonecfg.1m] man page.
* **`ncpus`** *(string, OPTIONAL)*
### Example
```json
"cappedCPU": {
"ncpus": "8"
}
```
## <a name="configSolarisCappedMemory" />cappedMemory
The physical and swap caps on the memory that can be used by this application container.
A scale (K, M, G, T) can be applied to the value for each of these numbers (for example, 1M is one megabyte).
cappedMemory is mapped to `capped-memory` in [zonecfg(1M)][zonecfg.1m] man page.
* **`physical`** *(string, OPTIONAL)*
* **`swap`** *(string, OPTIONAL)*
### Example
```json
"cappedMemory": {
"physical": "512m",
"swap": "512m"
}
```
## <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.
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.
For additional information on properties, check the [zonecfg(1M)][zonecfg.1m] man page for the respective release of Solaris.
* **`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] 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] 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] 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] man page of the respective Solaris release.
Mapped to `mac-address` in the [zonecfg(1M)][zonecfg.1m] 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] man page.
#### Example
```json
"anet": [
{
"allowedAddress": "172.17.0.2/16",
"configureAllowedAddress": "true",
"defrouter": "172.17.0.1/16",
"linkProtection": "mac-nospoof, ip-nospoof",
"linkname": "net0",
"lowerLink": "net2",
"macAddress": "02:42:f8:52:c7:16"
}
]
```
[priv-str-to-set.3c]: http://docs.oracle.com/cd/E53394_01/html/E54766/priv-str-to-set-3c.html
[zoneadmd.1m]: http://docs.oracle.com/cd/E53394_01/html/E54764/zoneadmd-1m.html
[zonecfg.1m_2]: http://docs.oracle.com/cd/E53394_01/html/E54764/zonecfg-1m.html

99
vendor/github.com/opencontainers/runtime-spec/config-windows.md generated vendored
View file

@ -1,99 +0,0 @@
# <a name="windowsSpecificContainerConfiguration" />Windows-specific Container Configuration
This document describes the schema for the [Windows-specific section](config.md#platform-specific-configuration) of the [container configuration](config.md).
The Windows container specification uses APIs provided by the Windows Host Compute Service (HCS) to fulfill the spec.
## <a name="configWindowsResources" />Resources
You can configure a container's resource limits via the OPTIONAL `resources` field of the Windows configuration.
### <a name="configWindowsMemory" />Memory
`memory` is an OPTIONAL configuration for the container's memory usage.
The following parameters can be specified:
* **`limit`** *(uint64, OPTIONAL)* - sets limit of memory usage in bytes.
* **`reservation`** *(uint64, OPTIONAL)* - sets the guaranteed minimum amount of memory for a container in bytes.
#### Example
```json
"windows": {
"resources": {
"memory": {
"limit": 2097152,
"reservation": 524288
}
}
}
```
### <a name="configWindowsCpu" />CPU
`cpu` is an OPTIONAL configuration for the container's CPU usage.
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. The range is from 1 to 10000.
* **`percent`** *(uint, OPTIONAL)* - specifies the percentage of available CPUs usable by the container.
#### Example
```json
"windows": {
"resources": {
"cpu": {
"percent": 50
}
}
}
```
### <a name="configWindowsStorage" />Storage
`storage` is an OPTIONAL configuration for the container's storage usage.
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
```json
"windows": {
"resources": {
"storage": {
"iops": 50
}
}
}
```
### <a name="configWindowsNetwork" />Network
`network` is an OPTIONAL configuration for the container's network usage.
The following parameters can be specified:
* **`egressBandwidth`** *(uint64, OPTIONAL)* - specified the maximum egress bandwidth in bytes per second for the container.
#### Example
```json
"windows": {
"resources": {
"network": {
"egressBandwidth": 1048577
}
}
}
```

839
vendor/github.com/opencontainers/runtime-spec/config.md generated vendored
View file

@ -1,839 +0,0 @@
# <a name="containerConfigurationFile" />Container Configuration file
The container's top-level directory MUST contain a configuration file called `config.json`.
The canonical schema is defined in this document, but there is a JSON Schema in [`schema/config-schema.json`](schema/config-schema.json) and Go bindings in [`specs-go/config.go`](specs-go/config.go).
[Platform](spec.md#platforms)-specific configuration schema are defined in the [platform-specific documents](#platform-specific-configuration) linked below.
For properties that are only defined for some [platforms](spec.md#platforms), the Go property has a `platform` tag listing those protocols (e.g. `platform:"linux,solaris"`).
The configuration file contains metadata necessary to implement standard operations against the container.
This includes the process to run, environment variables to inject, sandboxing features to use, etc.
Below is a detailed description of each field defined in the configuration format and valid values are specified.
Platform-specific fields are identified as such.
For all platform-specific configuration values, the scope defined below in the [Platform-specific configuration](#platform-specific-configuration) section applies.
## <a name="configSpecificationVersion" />Specification version
* **`ociVersion`** (string, REQUIRED) MUST be in [SemVer v2.0.0][semver-v2.0.0] format and specifies the version of the Open Container Runtime Specification with which the bundle complies.
The Open Container Runtime Specification follows semantic versioning and retains forward and backward compatibility within major versions.
For example, if a configuration is compliant with version 1.1 of this specification, it is compatible with all runtimes that support any 1.1 or later release of this specification, but is not compatible with a runtime that supports 1.0 and not 1.1.
### Example
```json
"ociVersion": "0.1.0"
```
## <a name="configRoot" />Root
**`root`** (object, REQUIRED) specifies the container's root filesystem.
* **`path`** (string, REQUIRED) Specifies the path to the root filesystem for the container.
The path is either an absolute path or a relative path to the bundle.
On Linux, for example, with a bundle at `/to/bundle` and a root filesystem at `/to/bundle/rootfs`, the `path` value can be either `/to/bundle/rootfs` or `rootfs`.
A directory MUST exist at the path declared by the field.
* **`readonly`** (bool, OPTIONAL) If true then the root filesystem MUST be read-only inside the container, defaults to false.
### Example
```json
"root": {
"path": "rootfs",
"readonly": true
}
```
## <a name="configMounts" />Mounts
**`mounts`** (array, OPTIONAL) specifies additional mounts beyond [`root`](#root-configuration).
The runtime MUST mount entries in the listed order.
For Linux, the parameters are as documented in [mount(2)][mount.2] system call man page.
For Solaris, the mount entry corresponds to the 'fs' resource in the [zonecfg(1M)][zonecfg.1m] man page.
For Windows, see [mountvol][mountvol] and [SetVolumeMountPoint][set-volume-mountpoint] for details.
* **`destination`** (string, REQUIRED) Destination of mount point: path inside container.
This value MUST be an absolute path.
* Windows: one mount destination MUST NOT be nested within another mount (e.g., c:\\foo and c:\\foo\\bar).
* Solaris: corresponds to "dir" of the fs resource in [zonecfg(1M)][zonecfg.1m].
* **`type`** (string, OPTIONAL) The filesystem type of the filesystem to be mounted.
* Linux: valid *filesystemtype* supported by the kernel as listed in */proc/filesystems* (e.g., "minix", "ext2", "ext3", "jfs", "xfs", "reiserfs", "msdos", "proc", "nfs", "iso9660").
* Windows: the type of file system on the volume, e.g. "ntfs".
* Solaris: corresponds to "type" of the fs resource in [zonecfg(1M)][zonecfg.1m].
* **`source`** (string, OPTIONAL) A device name, but can also be a directory name or a dummy.
* Windows: the volume name that is the target of the mount point, \\?\Volume\{GUID}\ (on Windows source is called target).
* Solaris: corresponds to "special" of the fs resource in [zonecfg(1M)][zonecfg.1m].
* **`options`** (list of strings, OPTIONAL) Mount options of the filesystem to be used.
* Linux: supported options are listed in the [mount(8)][mount.8] man page. Note both [filesystem-independent][mount.8-filesystem-independent] and [filesystem-specific][mount.8-filesystem-specific] options are listed.
* Solaris: corresponds to "options" of the fs resource in [zonecfg(1M)][zonecfg.1m].
### Example (Linux)
```json
"mounts": [
{
"destination": "/tmp",
"type": "tmpfs",
"source": "tmpfs",
"options": ["nosuid","strictatime","mode=755","size=65536k"]
},
{
"destination": "/data",
"type": "bind",
"source": "/volumes/testing",
"options": ["rbind","rw"]
}
]
```
### Example (Windows)
```json
"mounts": [
"myfancymountpoint": {
"destination": "C:\\Users\\crosbymichael\\My Fancy Mount Point\\",
"type": "ntfs",
"source": "\\\\?\\Volume\\{2eca078d-5cbc-43d3-aff8-7e8511f60d0e}\\",
"options": []
}
]
```
### Example (Solaris)
```json
"mounts": [
{
"destination": "/opt/local",
"type": "lofs",
"source": "/usr/local",
"options": ["ro","nodevices"]
},
{
"destination": "/opt/sfw",
"type": "lofs",
"source": "/opt/sfw"
}
]
```
## <a name="configProcess" />Process
**`process`** (object, REQUIRED) specifies the container process.
* **`terminal`** (bool, OPTIONAL) specifies whether a terminal is attached to that process, defaults to false.
As an example, if set to true on Linux a pseudoterminal pair is allocated for the container process and the pseudoterminal slave is duplicated on the container process's [standard streams][stdin.3].
* **`consoleSize`** (object, OPTIONAL) specifies the console size of the terminal if attached, containing the following properties:
* **`height`** (uint, REQUIRED)
* **`width`** (uint, REQUIRED)
* **`cwd`** (string, REQUIRED) is the working directory that will be set for the executable.
This value MUST be an absolute path.
* **`env`** (array of strings, OPTIONAL) with the same semantics as [IEEE Std 1003.1-2001's `environ`][ieee-1003.1-2001-xbd-c8.1].
* **`args`** (array of strings, REQUIRED) with similar semantics to [IEEE Std 1003.1-2001 `execvp`'s *argv*][ieee-1003.1-2001-xsh-exec].
This specification extends the IEEE standard in that at least one entry is REQUIRED, and that entry is used with the same semantics as `execvp`'s *file*.
* **`capabilities`** (object, OPTIONAL) is an object containing arrays that specifies the sets of capabilities for the process(es) inside the container. Valid values are platform-specific. For example, valid values for Linux are defined in the [capabilities(7)][capabilities.7] man page.
capabilities contains the following properties:
* **`effective`** (array of strings, OPTIONAL) - the `effective` field is an array of effective capabilities that are kept for the process.
* **`bounding`** (array of strings, OPTIONAL) - the `bounding` field is an array of bounding capabilities that are kept for the process.
* **`inheritable`** (array of strings, OPTIONAL) - the `inheritable` field is an array of inheritable capabilities that are kept for the process.
* **`permitted`** (array of strings, OPTIONAL) - the `permitted` field is an array of permitted capabilities that are kept for the process.
* **`ambient`** (array of strings, OPTIONAL) - the `ambient` field is an array of ambient capabilities that are kept for the process.
* **`rlimits`** (array of objects, OPTIONAL) allows setting resource limits for a process inside the container.
Each entry has the following structure:
* **`type`** (string, REQUIRED) - the platform resource being limited, for example on Linux as defined in the [setrlimit(2)][setrlimit.2] man page.
* **`soft`** (uint64, REQUIRED) - the value of the limit enforced for the corresponding resource.
* **`hard`** (uint64, REQUIRED) - the ceiling for the soft limit that could be set by an unprivileged process. Only a privileged process (e.g. under Linux: one with the CAP_SYS_RESOURCE capability) can raise a hard limit.
If `rlimits` contains duplicated entries with same `type`, the runtime MUST error out.
* **`noNewPrivileges`** (bool, OPTIONAL) setting `noNewPrivileges` to true prevents the processes in the container from gaining additional privileges.
As an example, the ['no_new_privs'][no-new-privs] article in the kernel documentation has information on how this is achieved using a prctl system call on Linux.
For Linux-based systems the process structure supports the following process specific fields.
* **`apparmorProfile`** (string, OPTIONAL) specifies the name of the AppArmor profile to be applied to processes in the container.
For more information about AppArmor, see [AppArmor documentation][apparmor].
* **`selinuxLabel`** (string, OPTIONAL) specifies the SELinux label to be applied to the processes in the container.
For more information about SELinux, see [SELinux documentation][selinux].
### <a name="configUser" />User
The user for the process is a platform-specific structure that allows specific control over which user the process runs as.
#### <a name="configLinuxAndSolarisUser" />Linux and Solaris User
For Linux and Solaris based systems the user structure has the following fields:
* **`uid`** (int, REQUIRED) specifies the user ID in the [container namespace](glossary.md#container-namespace).
* **`gid`** (int, REQUIRED) specifies the group ID in the [container namespace](glossary.md#container-namespace).
* **`additionalGids`** (array of ints, OPTIONAL) specifies additional group IDs (in the [container namespace](glossary.md#container-namespace) to be added to the process.
_Note: symbolic name for uid and gid, such as uname and gname respectively, are left to upper levels to derive (i.e. `/etc/passwd` parsing, NSS, etc)_
### Example (Linux)
```json
"process": {
"terminal": true,
"consoleSize": {
"height": 25,
"width": 80
},
"user": {
"uid": 1,
"gid": 1,
"additionalGids": [5, 6]
},
"env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"TERM=xterm"
],
"cwd": "/root",
"args": [
"sh"
],
"apparmorProfile": "acme_secure_profile",
"selinuxLabel": "system_u:system_r:svirt_lxc_net_t:s0:c124,c675",
"noNewPrivileges": true,
"capabilities": {
"bounding": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
],
"permitted": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
],
"inheritable": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
],
"effective": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
],
"ambient": [
"CAP_NET_BIND_SERVICE"
]
},
"rlimits": [
{
"type": "RLIMIT_NOFILE",
"hard": 1024,
"soft": 1024
}
]
}
```
### Example (Solaris)
```json
"process": {
"terminal": true,
"consoleSize": {
"height": 25,
"width": 80
},
"user": {
"uid": 1,
"gid": 1,
"additionalGids": [2, 8]
},
"env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"TERM=xterm"
],
"cwd": "/root",
"args": [
"/usr/bin/bash"
]
}
```
#### <a name="configWindowsUser" />Windows User
For Windows based systems the user structure has the following fields:
* **`username`** (string, OPTIONAL) specifies the user name for the process.
### Example (Windows)
```json
"process": {
"terminal": true,
"user": {
"username": "containeradministrator"
},
"env": [
"VARIABLE=1"
],
"cwd": "c:\\foo",
"args": [
"someapp.exe",
]
}
```
## <a name="configHostname" />Hostname
* **`hostname`** (string, OPTIONAL) specifies the container's hostname as seen by processes running inside the container.
On Linux, for example, this will change the hostname in the [container](glossary.md#container-namespace) [UTS namespace][uts-namespace.7].
Depending on your [namespace configuration](config-linux.md#namespaces), the container UTS namespace may be the [runtime UTS namespace](glossary.md#runtime-namespace).
### Example
```json
"hostname": "mrsdalloway"
```
## <a name="configPlatform" />Platform
**`platform`** (object, REQUIRED) specifies the configuration's target platform.
* **`os`** (string, REQUIRED) specifies the operating system family of the container configuration's specified [`root`](#root-configuration) file system bundle.
The runtime MUST generate an error if it does not support the specified **`os`**.
Bundles SHOULD use, and runtimes SHOULD understand, **`os`** entries listed in the Go Language document for [`$GOOS`][go-environment].
If an operating system is not included in the `$GOOS` documentation, it SHOULD be submitted to this specification for standardization.
* **`arch`** (string, REQUIRED) specifies the instruction set for which the binaries in the specified [`root`](#root-configuration) file system bundle have been compiled.
The runtime MUST generate an error if it does not support the specified **`arch`**.
Values for **`arch`** SHOULD use, and runtimes SHOULD understand, **`arch`** entries listed in the Go Language document for [`$GOARCH`][go-environment].
If an architecture is not included in the `$GOARCH` documentation, it SHOULD be submitted to this specification for standardization.
### Example
```json
"platform": {
"os": "linux",
"arch": "amd64"
}
```
## <a name="configPlatformSpecificConfiguration" />Platform-specific configuration
[**`platform.os`**](#platform) is used to specify platform-specific configuration.
Runtime implementations MAY support any valid values for platform-specific fields as part of this configuration.
Implementations MUST error out when invalid values are encountered and MUST generate an error message and error out when encountering valid values it chooses to not support.
* **`linux`** (object, OPTIONAL) [Linux-specific configuration](config-linux.md).
This MAY be set if **`platform.os`** is `linux` and MUST NOT be set otherwise.
* **`windows`** (object, OPTIONAL) [Windows-specific configuration](config-windows.md).
This MAY be set if **`platform.os`** is `windows` and MUST NOT be set otherwise.
* **`solaris`** (object, OPTIONAL) [Solaris-specific configuration](config-solaris.md).
This MAY be set if **`platform.os`** is `solaris` and MUST NOT be set otherwise.
### Example (Linux)
```json
{
"platform": {
"os": "linux",
"arch": "amd64"
},
"linux": {
"namespaces": [
{
"type": "pid"
}
]
}
}
```
## <a name="configHooks" />Hooks
Hooks allow for the configuration of custom actions related to the [lifecycle](runtime.md#lifecycle) of the container.
* **`hooks`** (object, OPTIONAL) MAY contain any of the following properties:
* **`prestart`** (array, OPTIONAL) is an array of [pre-start hooks](#prestart).
Entries in the array contain the following properties:
* **`path`** (string, REQUIRED) with similar semantics to [IEEE Std 1003.1-2001 `execv`'s *path*][ieee-1003.1-2001-xsh-exec].
This specification extends the IEEE standard in that **`path`** MUST be absolute.
* **`args`** (array of strings, OPTIONAL) with the same semantics as [IEEE Std 1003.1-2001 `execv`'s *argv*][ieee-1003.1-2001-xsh-exec].
* **`env`** (array of strings, OPTIONAL) with the same semantics as [IEEE Std 1003.1-2001's `environ`][ieee-1003.1-2001-xbd-c8.1].
* **`timeout`** (int, OPTIONAL) is the number of seconds before aborting the hook.
* **`poststart`** (array, OPTIONAL) is an array of [post-start hooks](#poststart).
Entries in the array have the same schema as pre-start entries.
* **`poststop`** (array, OPTIONAL) is an array of [post-stop hooks](#poststop).
Entries in the array have the same schema as pre-start entries.
Hooks allow users to specify programs to run before or after various lifecycle events.
Hooks MUST be called in the listed order.
The [state](runtime.md#state) of the container MUST be passed to hooks over stdin so that they may do work appropriate to the current state of the container.
### <a name="configHooksPrestart" />Prestart
The pre-start hooks MUST be called after the [`start`](runtime.md#start) operation is called but [before the user-specified program command is executed](runtime.md#lifecycle).
On Linux, for example, they are called after the container namespaces are created, so they provide an opportunity to customize the container (e.g. the network namespace could be specified in this hook).
### <a name="configHooksPoststart" />Poststart
The post-start hooks MUST be called [after the user-specified process is executed](runtime#lifecycle) but before the [`start`](runtime.md#start) operation returns.
For example, this hook can notify the user that the container process is spawned.
### <a name="configHooksPoststop" />Poststop
The post-stop hooks MUST be called [after the container is deleted](runtime#lifecycle) but before the [`delete`](runtime.md#delete) operation returns.
Cleanup or debugging functions are examples of such a hook.
### Example
```json
"hooks": {
"prestart": [
{
"path": "/usr/bin/fix-mounts",
"args": ["fix-mounts", "arg1", "arg2"],
"env": [ "key1=value1"]
},
{
"path": "/usr/bin/setup-network"
}
],
"poststart": [
{
"path": "/usr/bin/notify-start",
"timeout": 5
}
],
"poststop": [
{
"path": "/usr/sbin/cleanup.sh",
"args": ["cleanup.sh", "-f"]
}
]
}
```
## <a name="configAnnotations" />Annotations
**`annotations`** (object, OPTIONAL) contains arbitrary metadata for the container.
This information MAY be structured or unstructured.
Annotations MUST be a key-value map.
If there are no annotations then this property MAY either be absent or an empty map.
Keys MUST be strings.
Keys MUST be unique within this map.
Keys MUST NOT be an empty string.
Keys SHOULD be named using a reverse domain notation - e.g. `com.example.myKey`.
Keys using the `org.opencontainers` namespace are reserved and MUST NOT be used by subsequent specifications.
Implementations that are reading/processing this configuration file MUST NOT generate an error if they encounter an unknown annotation key.
Values MUST be strings.
Values MAY be an empty string.
```json
"annotations": {
"com.example.gpu-cores": "2"
}
```
## <a name="configExtensibility" />Extensibility
Implementations that are reading/processing this configuration file MUST NOT generate an error if they encounter an unknown property.
Instead they MUST ignore unknown properties.
## Configuration Schema Example
Here is a full example `config.json` for reference.
```json
{
"ociVersion": "0.5.0-dev",
"platform": {
"os": "linux",
"arch": "amd64"
},
"process": {
"terminal": true,
"user": {
"uid": 1,
"gid": 1,
"additionalGids": [
5,
6
]
},
"args": [
"sh"
],
"env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"TERM=xterm"
],
"cwd": "/",
"capabilities": {
"bounding": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
],
"permitted": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
],
"inheritable": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE"
],
"effective": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
],
"ambient": [
"CAP_NET_BIND_SERVICE"
]
},
"rlimits": [
{
"type": "RLIMIT_CORE",
"hard": 1024,
"soft": 1024
},
{
"type": "RLIMIT_NOFILE",
"hard": 1024,
"soft": 1024
}
],
"apparmorProfile": "acme_secure_profile",
"selinuxLabel": "system_u:system_r:svirt_lxc_net_t:s0:c124,c675",
"noNewPrivileges": true
},
"root": {
"path": "rootfs",
"readonly": true
},
"hostname": "slartibartfast",
"mounts": [
{
"destination": "/proc",
"type": "proc",
"source": "proc"
},
{
"destination": "/dev",
"type": "tmpfs",
"source": "tmpfs",
"options": [
"nosuid",
"strictatime",
"mode=755",
"size=65536k"
]
},
{
"destination": "/dev/pts",
"type": "devpts",
"source": "devpts",
"options": [
"nosuid",
"noexec",
"newinstance",
"ptmxmode=0666",
"mode=0620",
"gid=5"
]
},
{
"destination": "/dev/shm",
"type": "tmpfs",
"source": "shm",
"options": [
"nosuid",
"noexec",
"nodev",
"mode=1777",
"size=65536k"
]
},
{
"destination": "/dev/mqueue",
"type": "mqueue",
"source": "mqueue",
"options": [
"nosuid",
"noexec",
"nodev"
]
},
{
"destination": "/sys",
"type": "sysfs",
"source": "sysfs",
"options": [
"nosuid",
"noexec",
"nodev"
]
},
{
"destination": "/sys/fs/cgroup",
"type": "cgroup",
"source": "cgroup",
"options": [
"nosuid",
"noexec",
"nodev",
"relatime",
"ro"
]
}
],
"hooks": {
"prestart": [
{
"path": "/usr/bin/fix-mounts",
"args": [
"fix-mounts",
"arg1",
"arg2"
],
"env": [
"key1=value1"
]
},
{
"path": "/usr/bin/setup-network"
}
],
"poststart": [
{
"path": "/usr/bin/notify-start",
"timeout": 5
}
],
"poststop": [
{
"path": "/usr/sbin/cleanup.sh",
"args": [
"cleanup.sh",
"-f"
]
}
]
},
"linux": {
"devices": [
{
"path": "/dev/fuse",
"type": "c",
"major": 10,
"minor": 229,
"fileMode": 438,
"uid": 0,
"gid": 0
},
{
"path": "/dev/sda",
"type": "b",
"major": 8,
"minor": 0,
"fileMode": 432,
"uid": 0,
"gid": 0
}
],
"uidMappings": [
{
"hostID": 1000,
"containerID": 0,
"size": 32000
}
],
"gidMappings": [
{
"hostID": 1000,
"containerID": 0,
"size": 32000
}
],
"sysctl": {
"net.ipv4.ip_forward": "1",
"net.core.somaxconn": "256"
},
"cgroupsPath": "/myRuntime/myContainer",
"resources": {
"network": {
"classID": 1048577,
"priorities": [
{
"name": "eth0",
"priority": 500
},
{
"name": "eth1",
"priority": 1000
}
]
},
"pids": {
"limit": 32771
},
"hugepageLimits": [
{
"pageSize": "2MB",
"limit": 9223372036854772000
}
],
"oomScoreAdj": 100,
"memory": {
"limit": 536870912,
"reservation": 536870912,
"swap": 536870912,
"kernel": 0,
"kernelTCP": 0,
"swappiness": 0
},
"cpu": {
"shares": 1024,
"quota": 1000000,
"period": 500000,
"realtimeRuntime": 950000,
"realtimePeriod": 1000000,
"cpus": "2-3",
"mems": "0-7"
},
"disableOOMKiller": false,
"devices": [
{
"allow": false,
"access": "rwm"
},
{
"allow": true,
"type": "c",
"major": 10,
"minor": 229,
"access": "rw"
},
{
"allow": true,
"type": "b",
"major": 8,
"minor": 0,
"access": "r"
}
],
"blockIO": {
"blkioWeight": 10,
"blkioLeafWeight": 10,
"blkioWeightDevice": [
{
"major": 8,
"minor": 0,
"weight": 500,
"leafWeight": 300
},
{
"major": 8,
"minor": 16,
"weight": 500
}
],
"blkioThrottleReadBpsDevice": [
{
"major": 8,
"minor": 0,
"rate": 600
}
],
"blkioThrottleWriteIOPSDevice": [
{
"major": 8,
"minor": 16,
"rate": 300
}
]
}
},
"rootfsPropagation": "slave",
"seccomp": {
"defaultAction": "SCMP_ACT_ALLOW",
"architectures": [
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"getcwd",
"chmod"
],
"action": "SCMP_ACT_ERRNO",
"comment": "stop exploit x"
}
]
},
"namespaces": [
{
"type": "pid"
},
{
"type": "network"
},
{
"type": "ipc"
},
{
"type": "uts"
},
{
"type": "mount"
},
{
"type": "user"
},
{
"type": "cgroup"
}
],
"maskedPaths": [
"/proc/kcore",
"/proc/latency_stats",
"/proc/timer_stats",
"/proc/sched_debug"
],
"readonlyPaths": [
"/proc/asound",
"/proc/bus",
"/proc/fs",
"/proc/irq",
"/proc/sys",
"/proc/sysrq-trigger"
],
"mountLabel": "system_u:object_r:svirt_sandbox_file_t:s0:c715,c811"
},
"annotations": {
"com.example.key1": "value1",
"com.example.key2": "value2"
}
}
```
[apparmor]: https://wiki.ubuntu.com/AppArmor
[selinux]:http://selinuxproject.org/page/Main_Page
[no-new-privs]: https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt
[semver-v2.0.0]: http://semver.org/spec/v2.0.0.html
[go-environment]: https://golang.org/doc/install/source#environment
[ieee-1003.1-2001-xbd-c8.1]: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_01
[ieee-1003.1-2001-xsh-exec]: http://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html
[mountvol]: http://ss64.com/nt/mountvol.html
[set-volume-mountpoint]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365561(v=vs.85).aspx
[capabilities.7]: http://man7.org/linux/man-pages/man7/capabilities.7.html
[mount.2]: http://man7.org/linux/man-pages/man2/mount.2.html
[mount.8]: http://man7.org/linux/man-pages/man8/mount.8.html
[mount.8-filesystem-independent]: http://man7.org/linux/man-pages/man8/mount.8.html#FILESYSTEM-INDEPENDENT_MOUNT%20OPTIONS
[mount.8-filesystem-specific]: http://man7.org/linux/man-pages/man8/mount.8.html#FILESYSTEM-SPECIFIC_MOUNT%20OPTIONS
[setrlimit.2]: http://man7.org/linux/man-pages/man2/setrlimit.2.html
[stdin.3]: http://man7.org/linux/man-pages/man3/stdin.3.html
[uts-namespace.7]: http://man7.org/linux/man-pages/man7/namespaces.7.html
[zonecfg.1m]: http://docs.oracle.com/cd/E53394_01/html/E54764/zonecfg-1m.html

40
vendor/github.com/opencontainers/runtime-spec/glossary.md generated vendored
View file

@ -1,40 +0,0 @@
# <a name="glossary" />Glossary
## <a name="glossaryBundle" />Bundle
A [directory structure](bundle.md) that is written ahead of time, distributed, and used to seed the runtime for creating a [container](#container) and launching a process within it.
## <a name="glossaryConfiguration" />Configuration
The [`config.json`](config.md) file in a [bundle](#bundle) which defines the intended [container](#container) and container process.
## <a name="glossaryContainer" />Container
An environment for executing processes with configurable isolation and resource limitations.
For example, namespaces, resource limits, and mounts are all part of the container environment.
## <a name="glossaryContainerNamespace" />Container namespace
On Linux, a leaf in the [namespace][namespaces.7] hierarchy in which the [configured process](config.md#process) executes.
## <a name="glossaryJson" />JSON
All configuration [JSON][] MUST be encoded in [UTF-8][].
JSON objects MUST NOT include duplicate names.
The order of entries in JSON objects is not significant.
## <a name="glossaryRuntime" />Runtime
An implementation of this specification.
It reads the [configuration files](#configuration) from a [bundle](#bundle), uses that information to create a [container](#container), launches a process inside the container, and performs other [lifecycle actions](runtime.md).
## <a name="glossaryRuntimeNamespace" />Runtime namespace
On Linux, a leaf in the [namespace][namespaces.7] hierarchy from which the [runtime](#runtime) process is executed.
New container namespaces will be created as children of the runtime namespaces.
[JSON]: https://tools.ietf.org/html/rfc7159
[UTF-8]: http://www.unicode.org/versions/Unicode8.0.0/ch03.pdf
[namespaces.7]: http://man7.org/linux/man-pages/man7/namespaces.7.html

27
vendor/github.com/opencontainers/runtime-spec/implementations.md generated vendored
View file

@ -1,27 +0,0 @@
# <a name="implementations" />Implementations
The following sections link to associated projects, some of which are maintained by the OCI and some of which are maintained by external organizations.
If you know of any associated projects that are not listed here, please file a pull request adding a link to that project.
## <a name"implementationsRuntimeContainer" />Runtime (Container)
* [opencontainers/runc][runc] - Reference implementation of OCI runtime
## <a name="implementationsRuntimeVirtualMachine" />Runtime (Virtual Machine)
* [hyperhq/runv][runv] - Hypervisor-based runtime for OCI
* [01org/cc-oci-runtime][cc-oci] - Hypervisor-based OCI runtime for Intel® Architecture
## <a name="implementationsTestingTools" />Testing & Tools
* [kunalkushwaha/octool][octool] - A config linter and validator.
* [huawei-openlab/oct][oct] - Open Container Testing framework for OCI configuration and runtime
* [opencontainers/runtime-tools][runtime-tools] - A config generator and runtime/bundle testing framework.
[runc]: https://github.com/opencontainers/runc
[runv]: https://github.com/hyperhq/runv
[cc-oci]: https://github.com/01org/cc-oci-runtime
[octool]: https://github.com/kunalkushwaha/octool
[oct]: https://github.com/huawei-openlab/oct
[runtime-tools]: https://github.com/opencontainers/runtime-tools

46
vendor/github.com/opencontainers/runtime-spec/principles.md generated vendored
View file

@ -1,46 +0,0 @@
# <a name="the5PrinciplesOfStandardContainers" />The 5 principles of Standard Containers
Define a unit of software delivery called a Standard Container.
The goal of a Standard Container is to encapsulate a software component and all its dependencies in a format that is self-describing and portable, so that any compliant runtime can run it without extra dependencies, regardless of the underlying machine and the contents of the container.
The specification for Standard Containers defines:
1. configuration file formats
2. a set of standard operations
3. an execution environment.
A great analogy for this is the physical shipping container used by the transportation industry.
Shipping containers are a fundamental unit of delivery, they can be lifted, stacked, locked, loaded, unloaded and labelled.
Irrespective of their contents, by standardizing the container itself it allowed for a consistent, more streamlined and efficient set of processes to be defined.
For software Standard Containers offer similar functionality by being the fundamental, standardized, unit of delivery for a software package.
## <a name="standardOperations" />1. Standard operations
Standard Containers define a set of STANDARD OPERATIONS.
They can be created, started, and stopped using standard container tools; copied and snapshotted using standard filesystem tools; and downloaded and uploaded using standard network tools.
## <a name="contentAgnostic" />2. Content-agnostic
Standard Containers are CONTENT-AGNOSTIC: all standard operations have the same effect regardless of the contents.
They are started in the same way whether they contain a postgres database, a php application with its dependencies and application server, or Java build artifacts.
## <a name="infrastructureAgnostic" />3. Infrastructure-agnostic
Standard Containers are INFRASTRUCTURE-AGNOSTIC: they can be run in any OCI supported infrastructure.
For example, a standard container can be bundled on a laptop, uploaded to cloud storage, downloaded, run and snapshotted by a build server at a fiber hotel in Virginia, uploaded to 10 staging servers in a home-made private cloud cluster, then sent to 30 production instances across 3 public cloud regions.
## <a name="designedForAutomation" />4. Designed for automation
Standard Containers are DESIGNED FOR AUTOMATION: because they offer the same standard operations regardless of content and infrastructure, Standard Containers, are extremely well-suited for automation.
In fact, you could say automation is their secret weapon.
Many things that once required time-consuming and error-prone human effort can now be programmed.
Before Standard Containers, by the time a software component ran in production, it had been individually built, configured, bundled, documented, patched, vendored, templated, tweaked and instrumented by 10 different people on 10 different computers.
Builds failed, libraries conflicted, mirrors crashed, post-it notes were lost, logs were misplaced, cluster updates were half-broken.
The process was slow, inefficient and cost a fortune - and was entirely different depending on the language and infrastructure provider.
## <a name="industrialGradeDelivery" />5. Industrial-grade delivery
Standard Containers make INDUSTRIAL-GRADE DELIVERY of software a reality.
Leveraging all of the properties listed above, Standard Containers are enabling large and small enterprises to streamline and automate their software delivery pipelines.
Whether it is in-house devOps flows, or external customer-based software delivery mechanisms, Standard Containers are changing the way the community thinks about software packaging and delivery.

12
vendor/github.com/opencontainers/runtime-spec/project.md generated vendored
View file

@ -1,12 +0,0 @@
# <a name="projectDocs" />Project docs
## <a name="projectReleaseProcess" />Release Process
* Increment version in [`specs-go/version.go`](specs-go/version.go)
* `git commit` version increment
* `git tag` the prior commit (preferably signed tag)
* `make docs` to produce PDF and HTML copies of the spec
* Make a [release][releases] for the version. Attach the produced docs.
[releases]: https://github.com/opencontainers/runtime-spec/releases

21
vendor/github.com/opencontainers/runtime-spec/runtime-linux.md generated vendored
View file

@ -1,21 +0,0 @@
# <a name="linuxRuntime" />Linux Runtime
## <a name="runtimeLinuxFileDescriptors" />File descriptors
By default, only the `stdin`, `stdout` and `stderr` file descriptors are kept open for the application by the runtime.
The runtime MAY pass additional file descriptors to the application to support features such as [socket activation][socket-activated-containers].
Some of the file descriptors MAY be redirected to `/dev/null` even though they are open.
## <a name="runtimeLinuxDevSymbolicLinks" /> Dev symbolic links
After the container has `/proc` mounted, the following standard symlinks MUST be setup within `/dev/` for the IO.
| Source | Destination |
| --------------- | ----------- |
| /proc/self/fd | /dev/fd |
| /proc/self/fd/0 | /dev/stdin |
| /proc/self/fd/1 | /dev/stdout |
| /proc/self/fd/2 | /dev/stderr |
[socket-activated-containers]: http://0pointer.de/blog/projects/socket-activated-containers.html

146
vendor/github.com/opencontainers/runtime-spec/runtime.md generated vendored
View file

@ -1,146 +0,0 @@
# <a name="runtimeAndLifecycle" />Runtime and Lifecycle
## <a name="runtimeScopeContainer" />Scope of a Container
Barring access control concerns, the entity using a runtime to create a container MUST be able to use the operations defined in this specification against that same container.
Whether other entities using the same, or other, instance of the runtime can see that container is out of scope of this specification.
## <a name="runtimeState" />State
The state of a container includes the following properties:
* **`ociVersion`** (string, REQUIRED) is the OCI specification version used when creating the container.
* **`id`** (string, REQUIRED) is the container's ID.
This MUST be unique across all containers on this host.
There is no requirement that it be unique across hosts.
* **`status`** (string, REQUIRED) is the runtime state of the container.
The value MAY be one of:
* `creating`: the container is being created (step 2 in the [lifecycle](#lifecycle))
* `created`: the runtime has finished the [create operation](#create) (after step 2 in the [lifecycle](#lifecycle)), and the container process has neither exited nor executed the user-specified program
* `running`: the container process has executed the user-specified program but has not exited (after step 4 in the [lifecycle](#lifecycle))
* `stopped`: the container process has exited (step 5 in the [lifecycle](#lifecycle))
Additional values MAY be defined by the runtime, however, they MUST be used to represent new runtime states not defined above.
* **`pid`** (int, REQUIRED when `status` is `created` or `running`) is the ID of the container process, as seen by the host.
* **`bundle`** (string, REQUIRED) is the absolute path to the container's bundle directory.
This is provided so that consumers can find the container's configuration and root filesystem on the host.
* **`annotations`** (map, OPTIONAL) contains the list of annotations associated with the container.
If no annotations were provided then this property MAY either be absent or an empty map.
The state MAY include additional properties.
When serialized in JSON, the format MUST adhere to the following pattern:
```json
{
"ociVersion": "0.2.0",
"id": "oci-container1",
"status": "running",
"pid": 4422,
"bundle": "/containers/redis",
"annotations": {
"myKey": "myValue"
}
}
```
See [Query State](#query-state) for information on retrieving the state of a container.
## <a name="runtimeLifecycle" />Lifecycle
The lifecycle describes the timeline of events that happen from when a container is created to when it ceases to exist.
1. OCI compliant runtime's [`create`](runtime.md#create) command is invoked with a reference to the location of the bundle and a unique identifier.
2. The container's runtime environment MUST be created according to the configuration in [`config.json`](config.md).
If the runtime is unable to create the environment specified in the [`config.json`](config.md), it MUST [generate an error](#errors).
While the resources requested in the [`config.json`](config.md) MUST be created, the user-specified program (from [`process`](config.md#process)) MUST NOT be run at this time.
Any updates to [`config.json`](config.md) after this step MUST NOT affect the container.
3. Once the container is created additional actions MAY be performed based on the features the runtime chooses to support.
However, some actions might only be available based on the current state of the container (e.g. only available while it is started).
4. Runtime's [`start`](runtime.md#start) command is invoked with the unique identifier of the container.
5. The [prestart hooks](config.md#prestart) MUST be invoked by the runtime.
If any prestart hook fails, the runtime MUST [generate an error](#errors), stop the container, and continue the lifecycle at step 10.
6. The runtime MUST run the user-specified program, as specified by [`process`](config.md#process).
7. The [poststart hooks](config.md#poststart) MUST be invoked by the runtime.
If any poststart hook fails, the runtime MUST [log a warning](#warnings), but the remaining hooks and lifecycle continue as if the hook had succeeded.
8. The container process exits.
This MAY happen due to erroring out, exiting, crashing or the runtime's [`kill`](runtime.md#kill) operation being invoked.
9. Runtime's [`delete`](runtime.md#delete) command is invoked with the unique identifier of the container.
10. The container MUST be destroyed by undoing the steps performed during create phase (step 2).
11. The [poststop hooks](config.md#poststop) MUST be invoked by the runtime.
If any poststop hook fails, the runtime MUST [log a warning](#warnings), but the remaining hooks and lifecycle continue as if the hook had succeeded.
## <a name="runtimeErrors" />Errors
In cases where the specified operation generates an error, this specification does not mandate how, or even if, that error is returned or exposed to the user of an implementation.
Unless otherwise stated, generating an error MUST leave the state of the environment as if the operation were never attempted - modulo any possible trivial ancillary changes such as logging.
## <a name="runtimeWarnings" />Warnings
In cases where the specified operation logs a warning, this specification does not mandate how, or even if, that warning is returned or exposed to the user of an implementation.
Unless otherwise stated, logging a warning does not change the flow of the operation; it MUST continue as if the warning had not been logged.
## <a name="runtimeOperations" />Operations
OCI compliant runtimes MUST support the following operations, unless the operation is not supported by the base operating system.
Note: these operations are not specifying any command-line APIs, and the parameters are inputs for general operations.
### <a name="runtimeQueryState" />Query State
`state <container-id>`
This operation MUST [generate an error](#errors) if it is not provided the ID of a container.
Attempting to query a container that does not exist MUST [generate an error](#errors).
This operation MUST return the state of a container as specified in the [State](#state) section.
### <a name="runtimeCreate" />Create
`create <container-id> <path-to-bundle>`
This operation MUST [generate an error](#errors) if it is not provided a path to the bundle and the container ID to associate with the container.
If the ID provided is not unique across all containers within the scope of the runtime, or is not valid in any other way, the implementation MUST [generate an error](#errors) and a new container MUST NOT be created.
Using the data in [`config.json`](config.md), this operation MUST create a new container.
This means that all of the resources associated with the container MUST be created, however, the user-specified program MUST NOT be run at this time.
If the runtime cannot create the container as specified in [`config.json`](config.md), it MUST [generate an error](#errors) and a new container MUST NOT be created.
Upon successful completion of this operation the `status` property of this container MUST be `created`.
The runtime MAY validate `config.json` against this spec, either generically or with respect to the local system capabilities, before creating the container ([step 2](#lifecycle)).
Runtime callers who are interested in pre-create validation can run [bundle-validation tools](implementations.md#testing--tools) before invoking the create operation.
Any changes made to the [`config.json`](config.md) file after this operation will not have an effect on the container.
### <a name="runtimeStart" />Start
`start <container-id>`
This operation MUST [generate an error](#errors) if it is not provided the container ID.
Attempting to start a container that does not exist MUST [generate an error](#errors).
Attempting to start an already started container MUST have no effect on the container and MUST [generate an error](#errors).
This operation MUST run the user-specified program as specified by [`process`](config.md#process).
Upon successful completion of this operation the `status` property of this container MUST be `running`.
### <a name="runtimeKill" />Kill
`kill <container-id> <signal>`
This operation MUST [generate an error](#errors) if it is not provided the container ID.
Attempting to send a signal to a container that is not running MUST have no effect on the container and MUST [generate an error](#errors).
This operation MUST send the specified signal to the process in the container.
When the process in the container is stopped, irrespective of it being as a result of a `kill` operation or any other reason, the `status` property of this container MUST be `stopped`.
### <a name="runtimeDelete" />Delete
`delete <container-id>`
This operation MUST [generate an error](#errors) if it is not provided the container ID.
Attempting to delete a container that does not exist MUST [generate an error](#errors).
Attempting to delete a container whose process is still running MUST [generate an error](#errors).
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.
## <a name="runtimeHooks" />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.

16
vendor/github.com/opencontainers/runtime-spec/schema/Makefile generated vendored
View file

@ -1,16 +0,0 @@
default: help
help:
@echo "Usage: make <target>"
@echo
@echo " * 'fmt' - format the json with indentation"
@echo " * 'validate' - build the validation tool"
fmt:
for i in *.json ; do jq --indent 4 -M . "$${i}" > xx && cat xx > "$${i}" && rm xx ; done
validate: validate.go
go get -d ./...
go build ./validate.go

47
vendor/github.com/opencontainers/runtime-spec/schema/README.md generated vendored
View file

@ -1,47 +0,0 @@
# JSON schema
## Overview
This directory contains the [JSON Schema](http://json-schema.org/) for validating JSON covered by this specification.
The layout of the files is as follows:
* [config-schema.json](config-schema.json) - the primary entrypoint for the [configuration](../config.md) schema
* [config-linux.json](config-linux.json) - the [Linux-specific configuration sub-structure](../config-linux.md)
* [config-solaris.json](config-solaris.json) - the [Solaris-specific configuration sub-structure](../config-solaris.md)
* [config-windows.json](config-windows.json) - the [Windows-specific configuration sub-structure](../config-windows.md)
* [state-schema.json](state-schema.json) - the primary entrypoint for the [state JSON](../runtime.md#state) schema
* [defs.json](defs.json) - definitions for general types
* [defs-linux.json](defs-linux.json) - definitions for Linux-specific types
* [validate.go](validate.go) - validation utility source code
## Utility
There is also included a simple utility for facilitating validation.
To build it:
```bash
export GOPATH=`mktemp -d`
go get -d ./...
go build ./validate.go
rm -rf $GOPATH
```
Or you can just use make command to create the utility:
```bash
make validate
```
Then use it like:
```bash
./validate config-schema.json <yourpath>/config.json
```
Or like:
```bash
./validate https://raw.githubusercontent.com/opencontainers/runtime-spec/v1.0.0-rc1/schema/schema.json <yourpath>/config.json
```

274
vendor/github.com/opencontainers/runtime-spec/schema/config-linux.json generated vendored
View file

@ -1,274 +0,0 @@
{
"linux": {
"description": "Linux platform-specific configurations",
"id": "https://opencontainers.org/schema/bundle/linux",
"type": "object",
"properties": {
"devices": {
"id": "https://opencontainers.org/schema/bundle/linux/devices",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/Device"
}
},
"uidMappings": {
"id": "https://opencontainers.org/schema/bundle/linux/uidMappings",
"type": "array",
"items": {
"$ref": "defs.json#/definitions/IDMapping"
}
},
"gidMappings": {
"id": "https://opencontainers.org/schema/bundle/linux/gidMappings",
"type": "array",
"items": {
"$ref": "defs.json#/definitions/IDMapping"
}
},
"namespaces": {
"id": "https://opencontainers.org/schema/bundle/linux/namespaces",
"type": "array",
"items": {
"anyOf": [
{
"$ref": "defs-linux.json#/definitions/NamespaceReference"
}
]
}
},
"resources": {
"id": "https://opencontainers.org/schema/bundle/linux/resources",
"type": "object",
"properties": {
"devices": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/devices",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/DeviceCgroup"
}
},
"oomScoreAdj": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/oomScoreAdj",
"type": "integer",
"minimum": -1000,
"maximum": 1000
},
"pids": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/pids",
"type": "object",
"properties": {
"limit": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/pids/limit",
"$ref": "defs.json#/definitions/int64"
}
},
"required": [
"limit"
]
},
"blockIO": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/blockIO",
"type": "object",
"properties": {
"blkioWeight": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/blockIO/blkioWeight",
"$ref": "defs-linux.json#/definitions/blkioWeight"
},
"blkioLeafWeight": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/blockIO/blkioLeafWeight",
"$ref": "defs-linux.json#/definitions/blkioWeight"
},
"blkioThrottleReadBpsDevice": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/blockIO/blkioThrottleReadBpsDevice",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/blockIODeviceThrottle"
}
},
"blkioThrottleWriteBpsDevice": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/blockIO/blkioThrottleWriteBpsDevice",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/blockIODeviceThrottle"
}
},
"blkioThrottleReadIopsDevice": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/blockIO/blkioThrottleReadIopsDevice",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/blockIODeviceThrottle"
}
},
"blkioThrottleWriteIopsDevice": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/blockIO/blkioThrottleWriteIopsDevice",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/blockIODeviceThrottle"
}
},
"blkioWeightDevice": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/blockIO/blkioWeightDevice",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/blockIODeviceWeight"
}
}
}
},
"cpu": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/cpu",
"type": "object",
"properties": {
"cpus": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/cpu/cpus",
"type": "string"
},
"mems": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/cpu/mems",
"type": "string"
},
"period": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/cpu/period",
"$ref": "defs.json#/definitions/uint64"
},
"quota": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/cpu/quota",
"$ref": "defs.json#/definitions/int64"
},
"realtimePeriod": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/cpu/realtimePeriod",
"$ref": "defs.json#/definitions/uint64"
},
"realtimeRuntime": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/cpu/realtimeRuntime",
"$ref": "defs.json#/definitions/int64"
},
"shares": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/cpu/shares",
"$ref": "defs.json#/definitions/uint64"
}
}
},
"disableOOMKiller": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/disableOOMKiller",
"type": "boolean"
},
"hugepageLimits": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/hugepageLimits",
"type": "array",
"items": {
"type": "object",
"properties": {
"pageSize": {
"type": "string"
},
"limit": {
"$ref": "defs.json#/definitions/uint64"
}
},
"required": [
"pageSize",
"limit"
]
}
},
"memory": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/memory",
"type": "object",
"properties": {
"kernel": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/memory/kernel",
"$ref": "defs.json#/definitions/uint64"
},
"kernelTCP": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/memory/kernelTCP",
"$ref": "defs.json#/definitions/uint64"
},
"limit": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/memory/limit",
"$ref": "defs.json#/definitions/uint64"
},
"reservation": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/memory/reservation",
"$ref": "defs.json#/definitions/uint64"
},
"swap": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/memory/swap",
"$ref": "defs.json#/definitions/uint64"
},
"swappiness": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/memory/swappiness",
"$ref": "defs.json#/definitions/uint64"
}
}
},
"network": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/network",
"type": "object",
"properties": {
"classID": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/network/classId",
"$ref": "defs.json#/definitions/uint32"
},
"priorities": {
"id": "https://opencontainers.org/schema/bundle/linux/resources/network/priorities",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/NetworkInterfacePriority"
}
}
}
}
}
},
"cgroupsPath": {
"id": "https://opencontainers.org/schema/bundle/linux/cgroupsPath",
"type": "string"
},
"rootfsPropagation": {
"id": "https://opencontainers.org/schema/bundle/linux/rootfsPropagation",
"type": "string"
},
"seccomp": {
"id": "https://opencontainers.org/schema/bundle/linux/seccomp",
"type": "object",
"properties": {
"defaultAction": {
"id": "https://opencontainers.org/schema/bundle/linux/seccomp/defaultAction",
"type": "string"
},
"architectures": {
"id": "https://opencontainers.org/schema/bundle/linux/seccomp/architectures",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/SeccompArch"
}
},
"syscalls": {
"id": "https://opencontainers.org/schema/bundle/linux/seccomp/syscalls",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/Syscall"
}
}
}
},
"sysctl": {
"id": "https://opencontainers.org/schema/bundle/linux/sysctl",
"$ref": "defs.json#/definitions/mapStringString"
},
"maskedPaths": {
"id": "https://opencontainers.org/schema/bundle/linux/maskedPaths",
"$ref": "defs.json#/definitions/ArrayOfStrings"
},
"readonlyPaths": {
"id": "https://opencontainers.org/schema/bundle/linux/readonlyPaths",
"$ref": "defs.json#/definitions/ArrayOfStrings"
},
"mountLabel": {
"id": "https://opencontainers.org/schema/bundle/linux/mountLabel",
"type": "string"
}
}
}
}

235
vendor/github.com/opencontainers/runtime-spec/schema/config-schema.json generated vendored
View file

@ -1,235 +0,0 @@
{
"description": "Open Container Runtime Specification Container Configuration Schema",
"$schema": "http://json-schema.org/draft-04/schema#",
"id": "https://opencontainers.org/schema/bundle",
"type": "object",
"properties": {
"ociVersion": {
"id": "https://opencontainers.org/schema/bundle/ociVersion",
"$ref": "defs.json#/definitions/ociVersion"
},
"hooks": {
"id": "https://opencontainers.org/schema/bundle/hooks",
"type": "object",
"properties": {
"prestart": {
"$ref": "defs.json#/definitions/ArrayOfHooks"
},
"poststart": {
"$ref": "defs.json#/definitions/ArrayOfHooks"
},
"poststop": {
"$ref": "defs.json#/definitions/ArrayOfHooks"
}
}
},
"annotations": {
"$ref": "defs.json#/definitions/annotations"
},
"hostname": {
"id": "https://opencontainers.org/schema/bundle/hostname",
"type": "string"
},
"mounts": {
"id": "https://opencontainers.org/schema/bundle/mounts",
"type": "array",
"items": {
"$ref": "defs.json#/definitions/Mount"
}
},
"platform": {
"id": "https://opencontainers.org/schema/bundle/platform",
"type": "object",
"required": [
"arch",
"os"
],
"properties": {
"arch": {
"id": "https://opencontainers.org/schema/bundle/platform/arch",
"type": "string"
},
"os": {
"id": "https://opencontainers.org/schema/bundle/platform/os",
"type": "string"
}
}
},
"root": {
"description": "Configures the container's root filesystem.",
"id": "https://opencontainers.org/schema/bundle/root",
"type": "object",
"required": [
"path"
],
"properties": {
"path": {
"id": "https://opencontainers.org/schema/bundle/root/path",
"$ref": "defs.json#/definitions/FilePath"
},
"readonly": {
"id": "https://opencontainers.org/schema/bundle/root/readonly",
"type": "boolean"
}
}
},
"process": {
"id": "https://opencontainers.org/schema/bundle/process",
"type": "object",
"required": [
"cwd",
"args"
],
"properties": {
"args": {
"id": "https://opencontainers.org/schema/bundle/process/args",
"$ref": "defs.json#/definitions/ArrayOfStrings"
},
"consoleSize": {
"id": "https://opencontainers.org/schema/bundle/process/consoleSize",
"type": "object",
"required": [
"height",
"width"
],
"properties": {
"height": {
"id": "https://opencontainers.org/schema/bundle/process/consoleSize/height",
"$ref": "defs.json#/definitions/uint64"
},
"width": {
"id": "https://opencontainers.org/schema/bundle/process/consoleSize/width",
"$ref": "defs.json#/definitions/uint64"
}
}
},
"cwd": {
"id": "https://opencontainers.org/schema/bundle/process/cwd",
"type": "string"
},
"env": {
"id": "https://opencontainers.org/schema/bundle/process/env",
"$ref": "defs.json#/definitions/Env"
},
"terminal": {
"id": "https://opencontainers.org/schema/bundle/process/terminal",
"type": "boolean"
},
"user": {
"id": "https://opencontainers.org/schema/bundle/process/user",
"type": "object",
"properties": {
"uid": {
"id": "https://opencontainers.org/schema/bundle/process/user/uid",
"$ref": "defs.json#/definitions/UID"
},
"gid": {
"id": "https://opencontainers.org/schema/bundle/process/user/gid",
"$ref": "defs.json#/definitions/GID"
},
"additionalGids": {
"id": "https://opencontainers.org/schema/bundle/process/user/additionalGids",
"$ref": "defs.json#/definitions/ArrayOfGIDs"
}
}
},
"capabilities": {
"id": "https://opencontainers.org/schema/bundle/process/linux/capabilities",
"type": "object",
"properties": {
"bounding": {
"id": "https://opencontainers.org/schema/bundle/process/linux/capabilities/bounding",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/Capability"
}
},
"permitted": {
"id": "https://opencontainers.org/schema/bundle/process/linux/capabilities/permitted",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/Capability"
}
},
"effective": {
"id": "https://opencontainers.org/schema/bundle/process/linux/capabilities/effective",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/Capability"
}
},
"inheritable": {
"id": "https://opencontainers.org/schema/bundle/process/linux/capabilities/inheritable",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/Capability"
}
},
"ambient": {
"id": "https://opencontainers.org/schema/bundle/process/linux/capabilities/ambient",
"type": "array",
"items": {
"$ref": "defs-linux.json#/definitions/Capability"
}
}
}
},
"apparmorProfile": {
"id": "https://opencontainers.org/schema/bundle/process/linux/apparmorProfile",
"type": "string"
},
"selinuxLabel": {
"id": "https://opencontainers.org/schema/bundle/process/linux/selinuxLabel",
"type": "string"
},
"noNewPrivileges": {
"id": "https://opencontainers.org/schema/bundle/process/linux/noNewPrivileges",
"type": "boolean"
},
"rlimits": {
"id": "https://opencontainers.org/schema/bundle/linux/rlimits",
"type": "array",
"items": {
"id": "https://opencontainers.org/schema/bundle/linux/rlimits/0",
"type": "object",
"required": [
"type",
"soft",
"hard"
],
"properties": {
"hard": {
"id": "https://opencontainers.org/schema/bundle/linux/rlimits/0/hard",
"$ref": "defs.json#/definitions/uint64"
},
"soft": {
"id": "https://opencontainers.org/schema/bundle/linux/rlimits/0/soft",
"$ref": "defs.json#/definitions/uint64"
},
"type": {
"id": "https://opencontainers.org/schema/bundle/linux/rlimits/0/type",
"type": "string",
"pattern": "^RLIMIT_[A-Z]+$"
}
}
}
}
}
},
"linux": {
"$ref": "config-linux.json#/linux"
},
"solaris": {
"$ref": "config-solaris.json#/solaris"
},
"windows": {
"$ref": "config-windows.json#/windows"
}
},
"required": [
"ociVersion",
"platform",
"process",
"root"
]
}

36
vendor/github.com/opencontainers/runtime-spec/schema/config-solaris.json generated vendored
View file

@ -1,36 +0,0 @@
{
"solaris": {
"description": "Solaris platform-specific configurations",
"id": "https://opencontainers.org/schema/bundle/solaris",
"type": "object",
"properties": {
"milestone": {
"id": "https://opencontainers.org/schema/bundle/solaris/milestone",
"type": "string"
},
"limitpriv": {
"id": "https://opencontainers.org/schema/bundle/solaris/limitpriv",
"type": "string"
},
"maxShmMemory": {
"id": "https://opencontainers.org/schema/bundle/solaris/maxShmMemory",
"type": "string"
},
"cappedCPU": {
"id": "https://opencontainers.org/schema/bundle/solaris/cappedCPU",
"$ref": "defs.json#/definitions/mapStringString"
},
"cappedMemory": {
"id": "https://opencontainers.org/schema/bundle/solaris/cappedMemory",
"$ref": "defs.json#/definitions/mapStringString"
},
"anet": {
"id": "https://opencontainers.org/schema/bundle/solaris/anet",
"type": "array",
"items": {
"$ref": "defs.json#/definitions/mapStringString"
}
}
}
}
}

75
vendor/github.com/opencontainers/runtime-spec/schema/config-windows.json generated vendored
View file

@ -1,75 +0,0 @@
{
"windows": {
"description": "Windows platform-specific configurations",
"id": "https://opencontainers.org/schema/bundle/windows",
"type": "object",
"properties": {
"resources": {
"id": "https://opencontainers.org/schema/bundle/windows/resources",
"type": "object",
"properties": {
"memory": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/memory",
"type": "object",
"properties": {
"limit": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/memory/limit",
"$ref": "defs.json#/definitions/uint64"
},
"reservation": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/memory/reservation",
"$ref": "defs.json#/definitions/uint64"
}
}
},
"cpu": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/cpu",
"type": "object",
"properties": {
"count": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/cpu/count",
"$ref": "defs.json#/definitions/uint64"
},
"shares": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/cpu/shares",
"$ref": "defs-windows.json#/definitions/cpuShares"
},
"percent": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/cpu/percent",
"$ref": "defs.json#/definitions/percent"
}
}
},
"storage": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/storage",
"type": "object",
"properties": {
"iops": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/storage/iops",
"$ref": "defs.json#/definitions/uint64"
},
"bps": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/storage/bps",
"$ref": "defs.json#/definitions/uint64"
},
"sandboxSize": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/storage/sandboxSize",
"$ref": "defs.json#/definitions/uint64"
}
}
},
"network": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/network",
"type": "object",
"properties": {
"egressBandwidth": {
"id": "https://opencontainers.org/schema/bundle/windows/resources/network/egressBandwidth",
"$ref": "defs.json#/definitions/uint64"
}
}
}
}
}
}
}
}

257
vendor/github.com/opencontainers/runtime-spec/schema/defs-linux.json generated vendored
View file

@ -1,257 +0,0 @@
{
"definitions": {
"SeccompArch": {
"type": "string",
"enum": [
"SCMP_ARCH_X86",
"SCMP_ARCH_X86_64",
"SCMP_ARCH_X32",
"SCMP_ARCH_ARM",
"SCMP_ARCH_AARCH64",
"SCMP_ARCH_MIPS",
"SCMP_ARCH_MIPS64",
"SCMP_ARCH_MIPS64N32",
"SCMP_ARCH_MIPSEL",
"SCMP_ARCH_MIPSEL64",
"SCMP_ARCH_MIPSEL64N32",
"SCMP_ARCH_PPC",
"SCMP_ARCH_PPC64",
"SCMP_ARCH_PPC64LE",
"SCMP_ARCH_S390",
"SCMP_ARCH_S390X",
"SCMP_ARCH_PARISC",
"SCMP_ARCH_PARISC64"
]
},
"SeccompAction": {
"type": "string",
"enum": [
"SCMP_ACT_KILL",
"SCMP_ACT_TRAP",
"SCMP_ACT_ERRNO",
"SCMP_ACT_TRACE",
"SCMP_ACT_ALLOW"
]
},
"SeccompOperators": {
"type": "string",
"enum": [
"SCMP_CMP_NE",
"SCMP_CMP_LT",
"SCMP_CMP_LE",
"SCMP_CMP_EQ",
"SCMP_CMP_GE",
"SCMP_CMP_GT",
"SCMP_CMP_MASKED_EQ"
]
},
"SyscallArg": {
"type": "object",
"properties": {
"index": {
"$ref": "defs.json#/definitions/uint32"
},
"value": {
"$ref": "defs.json#/definitions/uint64"
},
"valueTwo": {
"$ref": "defs.json#/definitions/uint64"
},
"op": {
"$ref": "#/definitions/SeccompOperators"
}
}
},
"Syscall": {
"type": "object",
"properties": {
"names": {
"type": [
"string"
]
},
"action": {
"$ref": "#/definitions/SeccompAction"
},
"args": {
"type": "array",
"items": {
"$ref": "#/definitions/SyscallArg"
}
}
}
},
"Capability": {
"description": "Linux process capabilities",
"type": "string",
"pattern": "^CAP_([A-Z]|_)+$"
},
"Major": {
"description": "major device number",
"$ref": "defs.json#/definitions/int64"
},
"Minor": {
"description": "minor device number",
"$ref": "defs.json#/definitions/int64"
},
"FileMode": {
"description": "File permissions mode (typically an octal value)",
"type": "integer",
"minimum": 0,
"maximum": 512
},
"FileType": {
"description": "Type of a block or special character device",
"type": "string",
"pattern": "^[cbup]$"
},
"Device": {
"type": "object",
"required": [
"type",
"path"
],
"properties": {
"type": {
"$ref": "#/definitions/FileType"
},
"path": {
"$ref": "defs.json#/definitions/FilePath"
},
"fileMode": {
"$ref": "#/definitions/FileMode"
},
"major": {
"$ref": "#/definitions/Major"
},
"minor": {
"$ref": "#/definitions/Minor"
},
"uid": {
"$ref": "defs.json#/definitions/UID"
},
"gid": {
"$ref": "defs.json#/definitions/GID"
}
}
},
"blkioWeight": {
"type": "integer",
"minimum": 10,
"maximum": 1000
},
"blockIODevice": {
"type": "object",
"properties": {
"major": {
"$ref": "#/definitions/Major"
},
"minor": {
"$ref": "#/definitions/Minor"
}
},
"required": [
"major",
"minor"
]
},
"blockIODeviceWeight": {
"type": "object",
"allOf": [
{
"$ref": "#/definitions/blockIODevice"
},
{
"type": "object",
"properties": {
"weight": {
"$ref": "#/definitions/blkioWeight"
},
"leafWeight": {
"$ref": "#/definitions/blkioWeight"
}
}
}
]
},
"blockIODeviceThrottle": {
"allOf": [
{
"$ref": "#/definitions/blockIODevice"
},
{
"type": "object",
"properties": {
"rate": {
"$ref": "defs.json#/definitions/uint64"
}
}
}
]
},
"DeviceCgroup": {
"type": "object",
"properties": {
"allow": {
"type": "boolean"
},
"type": {
"type": "string"
},
"major": {
"$ref": "#/definitions/Major"
},
"minor": {
"$ref": "#/definitions/Minor"
},
"access": {
"type": "string"
}
},
"required": [
"allow"
]
},
"NetworkInterfacePriority": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"priority": {
"$ref": "defs.json#/definitions/uint32"
}
},
"required": [
"name",
"priority"
]
},
"NamespaceType": {
"type": "string",
"enum": [
"mount",
"pid",
"network",
"uts",
"ipc",
"user",
"cgroup"
]
},
"NamespaceReference": {
"type": "object",
"properties": {
"type": {
"$ref": "#/definitions/NamespaceType"
},
"path": {
"$ref": "defs.json#/definitions/FilePath"
}
},
"required": [
"type"
]
}
}
}

10
vendor/github.com/opencontainers/runtime-spec/schema/defs-windows.json generated vendored
View file

@ -1,10 +0,0 @@
{
"definitions": {
"cpuShares": {
"description": "Relative weight to other containers with CPU Shares defined",
"type": "integer",
"minimum": 1,
"maximum": 10000
}
}
}

154
vendor/github.com/opencontainers/runtime-spec/schema/defs.json generated vendored
View file

@ -1,154 +0,0 @@
{
"description": "Definitions used throughout the Open Container Runtime Specification",
"definitions": {
"int8": {
"type": "integer",
"minimum": -128,
"maximum": 127
},
"int16": {
"type": "integer",
"minimum": -32768,
"maximum": 32767
},
"int32": {
"type": "integer",
"minimum": -2147483648,
"maximum": 2147483647
},
"int64": {
"type": "integer",
"minimum": -9223372036854776000,
"maximum": 9223372036854776000
},
"uint8": {
"type": "integer",
"minimum": 0,
"maximum": 255
},
"uint16": {
"type": "integer",
"minimum": 0,
"maximum": 65535
},
"uint32": {
"type": "integer",
"minimum": 0,
"maximum": 4294967295
},
"uint64": {
"type": "integer",
"minimum": 0,
"maximum": 18446744073709552000
},
"percent": {
"type": "integer",
"minimum": 0,
"maximum": 100
},
"mapStringString": {
"type": "object",
"patternProperties": {
".{1,}": {
"type": "string"
}
}
},
"UID": {
"$ref": "#/definitions/uint32"
},
"GID": {
"$ref": "#/definitions/uint32"
},
"ArrayOfGIDs": {
"type": "array",
"items": {
"$ref": "#/definitions/GID"
}
},
"ArrayOfStrings": {
"type": "array",
"items": {
"type": "string"
}
},
"FilePath": {
"type": "string"
},
"Env": {
"$ref": "#/definitions/ArrayOfStrings"
},
"Hook": {
"type": "object",
"properties": {
"path": {
"$ref": "#/definitions/FilePath"
},
"args": {
"$ref": "#/definitions/ArrayOfStrings"
},
"env": {
"$ref": "#/definitions/Env"
},
"timeout": {
"type": "integer"
}
},
"required": [
"path"
]
},
"ArrayOfHooks": {
"type": "array",
"items": {
"$ref": "#/definitions/Hook"
}
},
"IDMapping": {
"type": "object",
"properties": {
"hostID": {
"$ref": "#/definitions/uint32"
},
"containerID": {
"$ref": "#/definitions/uint32"
},
"size": {
"$ref": "#/definitions/uint32"
}
},
"required": [
"hostID",
"containerID",
"size"
]
},
"Mount": {
"type": "object",
"properties": {
"source": {
"$ref": "#/definitions/FilePath"
},
"destination": {
"$ref": "#/definitions/FilePath"
},
"options": {
"$ref": "#/definitions/ArrayOfStrings"
},
"type": {
"type": "string"
}
},
"required": [
"destination"
]
},
"ociVersion": {
"description": "The version of Open Container Runtime Specification that the document complies with",
"type": "string"
},
"annotations": {
"$ref": "#/definitions/mapStringString"
}
}
}

46
vendor/github.com/opencontainers/runtime-spec/schema/state-schema.json generated vendored
View file

@ -1,46 +0,0 @@
{
"description": "Open Container Runtime State Schema",
"$schema": "http://json-schema.org/draft-04/schema#",
"id": "https://opencontainers.org/schema/state",
"type": "object",
"properties": {
"ociVersion": {
"id": "https://opencontainers.org/schema/runtime/state/ociVersion",
"$ref": "defs.json#/definitions/ociVersion"
},
"id": {
"id": "https://opencontainers.org/schema/runtime/state/id",
"description": "the container's ID",
"type": "string"
},
"status": {
"id": "https://opencontainers.org/schema/runtime/state/status",
"type": "string",
"enum": [
"creating",
"created",
"running",
"stopped"
]
},
"pid": {
"id": "https://opencontainers.org/schema/runtime/state/pid",
"type": "integer",
"minimum": 0
},
"bundle": {
"id": "https://opencontainers.org/schema/runtime/state/bundle",
"type": "string"
},
"annotations": {
"$ref": "defs.json#/definitions/annotations"
}
},
"required": [
"ociVersion",
"id",
"status",
"pid",
"bundle"
]
}

100
vendor/github.com/opencontainers/runtime-spec/schema/validate.go generated vendored
View file

@ -1,100 +0,0 @@
package main
import (
"fmt"
"io/ioutil"
"os"
"path/filepath"
"strings"
"github.com/xeipuuv/gojsonschema"
)
const usage = `Validate is used to check document with specified schema.
You can use validate in following ways:
1.specify document file as an argument
validate <schema.json> <document.json>
2.pass document content through a pipe
cat <document.json> | validate <schema.json>
3.input document content manually, ended with ctrl+d(or your self-defined EOF keys)
validate <schema.json>
[INPUT DOCUMENT CONTENT HERE]
`
func main() {
nargs := len(os.Args[1:])
if nargs == 0 || nargs > 2 {
fmt.Printf("ERROR: invalid arguments number\n\n%s\n", usage)
os.Exit(1)
}
if os.Args[1] == "help" ||
os.Args[1] == "--help" ||
os.Args[1] == "-h" {
fmt.Printf("%s\n", usage)
os.Exit(1)
}
schemaPath := os.Args[1]
if !strings.Contains(schemaPath, "://") {
var err error
schemaPath, err = formatFilePath(schemaPath)
if err != nil {
fmt.Printf("ERROR: invalid schema-file path: %s\n", err)
os.Exit(1)
}
schemaPath = "file://" + schemaPath
}
schemaLoader := gojsonschema.NewReferenceLoader(schemaPath)
var documentLoader gojsonschema.JSONLoader
if nargs > 1 {
documentPath, err := formatFilePath(os.Args[2])
if err != nil {
fmt.Printf("ERROR: invalid document-file path: %s\n", err)
os.Exit(1)
}
documentLoader = gojsonschema.NewReferenceLoader("file://" + documentPath)
} else {
documentBytes, err := ioutil.ReadAll(os.Stdin)
if err != nil {
fmt.Println(err)
os.Exit(1)
}
documentString := string(documentBytes)
documentLoader = gojsonschema.NewStringLoader(documentString)
}
result, err := gojsonschema.Validate(schemaLoader, documentLoader)
if err != nil {
fmt.Println(err)
os.Exit(1)
}
if result.Valid() {
fmt.Printf("The document is valid\n")
} else {
fmt.Printf("The document is not valid. see errors :\n")
for _, desc := range result.Errors() {
fmt.Printf("- %s\n", desc)
}
os.Exit(1)
}
}
func formatFilePath(path string) (string, error) {
if _, err := os.Stat(path); err != nil {
return "", err
}
absPath, err := filepath.Abs(path)
if err != nil {
return "", err
}
return absPath, nil
}

46
vendor/github.com/opencontainers/runtime-spec/spec.md generated vendored
View file

@ -1,46 +0,0 @@
# <a name="openContainerInitiativeRuntimeSpecification" />Open Container Initiative Runtime Specification
The [Open Container Initiative][oci] develops specifications for standards on Operating System process and application containers.
# <a name="ociRuntimeSpecAbstract" />Abstract
The OCI Runtime Specification aims to specify the configuration, execution environment, and lifecycle a container.
A container's configuration is specified as the `config.json` for the supported platforms and details the fields that enable the creation of a container.
The execution environment is specified to ensure that applications running inside a container have a consistent environment between runtimes along with common actions defined for the container's lifecycle.
# <a name="ociRuntimeSpecPlatforms" />Platforms
Platforms defined by this specification are:
* `linux`: [runtime.md](runtime.md), [config.md](config.md), [config-linux.md](config-linux.md), and [runtime-linux.md](runtime-linux.md).
* `solaris`: [runtime.md](runtime.md), [config.md](config.md), and [config-solaris.md](config-solaris.md).
* `windows`: [runtime.md](runtime.md), [config.md](config.md), and [config-windows.md](config-windows.md).
# <a name="ociRuntimeSpecTOC" />Table of Contents
- [Introduction](spec.md)
- [Notational Conventions](#notational-conventions)
- [Container Principles](principles.md)
- [Filesystem Bundle](bundle.md)
- [Runtime and Lifecycle](runtime.md)
- [Linux-specific Runtime and Lifecycle](runtime-linux.md)
- [Configuration](config.md)
- [Linux-specific Configuration](config-linux.md)
- [Solaris-specific Configuration](config-solaris.md)
- [Windows-specific Configuration](config-windows.md)
- [Glossary](glossary.md)
# <a name="ociRuntimeSpecNotationalConventions" />Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119][rfc2119].
The key words "unspecified", "undefined", and "implementation-defined" are to be interpreted as described in the [rationale for the C99 standard][c99-unspecified].
An implementation is not compliant for a given CPU architecture if it fails to satisfy one or more of the MUST, REQUIRED, or SHALL requirements for the [platforms](#platforms) it implements.
An implementation is compliant for a given CPU architecture if it satisfies all the MUST, REQUIRED, and SHALL requirements for the [platforms](#platforms) it implements.
[c99-unspecified]: http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf#page=18
[oci]: http://www.opencontainers.org
[rfc2119]: http://tools.ietf.org/html/rfc2119

133
vendor/github.com/opencontainers/runtime-spec/style.md generated vendored
View file

@ -1,133 +0,0 @@
# <a name="styleAndConventions" />Style and conventions
## <a name="styleOneSentence" />One sentence per line
To keep consistency throughout the Markdown files in the Open Container spec all files should be formatted one sentence per line.
This fixes two things: it makes diffing easier with git and it resolves fights about line wrapping length.
For example, this paragraph will span three lines in the Markdown source.
## <a name="styleHex" />Traditionally hex settings should use JSON integers, not JSON strings
For example, [`"classID": 1048577`][class-id] instead of `"classID": "0x100001"`.
The config JSON isn't enough of a UI to be worth jumping through string <-> integer hoops to support an 0x… form ([source][integer-over-hex]).
## <a name="styleConstantNames" />Constant names should keep redundant prefixes
For example, `CAP_KILL` instead of `KILL` in [**`linux.capabilities`**][capabilities].
The redundancy reduction from removing the namespacing prefix is not useful enough to be worth trimming the upstream identifier ([source][keep-prefix]).
## <a name="styleOptionalSettings" />Optional settings should not have pointer Go types
Because in many cases the Go default for the type is a no-op in the spec (sources [here][no-pointer-for-strings], [here][no-pointer-for-slices], and [here][no-pointer-for-boolean]).
The exceptions are entries where we need to distinguish between “not set” and “set to the Go default for that type” ([source][pointer-when-updates-require-changes]), and this decision should be made on a per-setting case.
## Links
Internal links should be [relative links][markdown-relative-links] when linking to content within the repository.
Internal links should be used inline.
External links should be collected at the bottom of a markdown file and used as referenced links.
See 'Referenced Links' in this [markdown quick reference][markdown-quick-reference].
The use of referenced links in the markdown body helps to keep files clean and organized.
This also facilitates updates of external link targets on a per-file basis.
Referenced links should be kept in two alphabetically sorted sets, a general reference section followed by a man page section.
To keep Pandoc happy, duplicate naming of links within pages listed in the Makefile's DOC_FILES variable should be avoided by appending an '_N' to the link tagname, where 'N' is some number not currently in use.
The organization and style of an existing reference section should be maintained unless it violates these style guidelines.
An exception to these rules is when a URL is needed contextually, for example when showing an explicit link to the reader.
## Examples
### <a name="styleAnchoring" />Anchoring
For any given section that provides a notable example, it is ideal to have it denoted with [markdown headers][markdown-headers].
The level of header should be such that it is a subheader of the header it is an example of.
#### Example
```markdown
## Some Topic
### Some Subheader
#### Further Subheader
##### Example
To use Further Subheader, ...
### Example
To use Some Topic, ...
```
### <a name="styleContent" />Content
Where necessary, the values in the example can be empty or unset, but accommodate with comments regarding this intention.
Where feasible, the content and values used in an example should convey the fullest use of the data structures concerned.
Most commonly onlookers will intend to copy-and-paste a "working example".
If the intention of the example is to be a fully utilized example, rather than a copy-and-paste example, perhaps add a comment as such.
```markdown
### Example
```
```json
{
"foo": null,
"bar": ""
}
```
**vs.**
```markdown
### Example
Following is a fully populated example (not necessarily for copy/paste use)
```
```json
{
"foo": [
1,
2,
3
],
"bar": "waffles",
"bif": {
"baz": "potatoes"
}
}
```
### Links
The following is an example of different types of links.
This is shown as a complete markdown file, where the referenced links are at the bottom.
```markdown
The specification repository's [glossary](glossary.md) is where readers can find definitions of commonly used terms.
Readers may click through to the [Open Containers namespace][open-containers] on [GitHub][github].
The URL for the Open Containers link above is: https://github.com/opencontainers
[github]: https://github.com
[open-containers]: https://github.com/opencontainers
```
[capabilities]: config-linux.md#capabilities
[class-id]: config-linux.md#network
[integer-over-hex]: https://github.com/opencontainers/runtime-spec/pull/267#r48360013
[keep-prefix]: https://github.com/opencontainers/runtime-spec/pull/159#issuecomment-138728337
[no-pointer-for-boolean]: https://github.com/opencontainers/runtime-spec/pull/290#r50296396
[no-pointer-for-slices]: https://github.com/opencontainers/runtime-spec/pull/316#r50782982
[no-pointer-for-strings]: https://github.com/opencontainers/runtime-spec/pull/653#issue-200439192
[pointer-when-updates-require-changes]: https://github.com/opencontainers/runtime-spec/pull/317#r50932706
[markdown-headers]: https://help.github.com/articles/basic-writing-and-formatting-syntax/#headings
[markdown-quick-reference]: https://en.support.wordpress.com/markdown-quick-reference
[markdown-relative-links]: https://help.github.com/articles/basic-writing-and-formatting-syntax/#relative-links