diff --git a/Godeps/Godeps.json b/Godeps/Godeps.json index a85e3d3a..24c1afbc 100644 --- a/Godeps/Godeps.json +++ b/Godeps/Godeps.json @@ -57,9 +57,9 @@ "Rev": "f7137ae6b19afbfd61a94b746fda3b3fe0491874" }, { - "ImportPath": "github.com/opencontainers/specs/specs-go", - "Comment": "v0.4.0-35-g93ca97e", - "Rev": "93ca97e83ca7fb4fba6d9e30d5470f99ddc02d11" + "ImportPath": "github.com/opencontainers/runtime-spec/specs-go", + "Comment": "v0.5.0", + "Rev": "78e6667ae2d67aad100b28ee9580b41b7a24e667" }, { "ImportPath": "github.com/seccomp/libseccomp-golang", diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/LICENSE b/Godeps/_workspace/src/github.com/opencontainers/runtime-spec/LICENSE similarity index 100% rename from Godeps/_workspace/src/github.com/opencontainers/specs/LICENSE rename to Godeps/_workspace/src/github.com/opencontainers/runtime-spec/LICENSE diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/specs-go/config.go b/Godeps/_workspace/src/github.com/opencontainers/runtime-spec/specs-go/config.go similarity index 100% rename from Godeps/_workspace/src/github.com/opencontainers/specs/specs-go/config.go rename to Godeps/_workspace/src/github.com/opencontainers/runtime-spec/specs-go/config.go diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/specs-go/state.go b/Godeps/_workspace/src/github.com/opencontainers/runtime-spec/specs-go/state.go similarity index 100% rename from Godeps/_workspace/src/github.com/opencontainers/specs/specs-go/state.go rename to Godeps/_workspace/src/github.com/opencontainers/runtime-spec/specs-go/state.go diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/specs-go/version.go b/Godeps/_workspace/src/github.com/opencontainers/runtime-spec/specs-go/version.go similarity index 96% rename from Godeps/_workspace/src/github.com/opencontainers/specs/specs-go/version.go rename to Godeps/_workspace/src/github.com/opencontainers/runtime-spec/specs-go/version.go index 27f45e08..67f1a9d9 100644 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/specs-go/version.go +++ b/Godeps/_workspace/src/github.com/opencontainers/runtime-spec/specs-go/version.go @@ -11,7 +11,7 @@ const ( VersionPatch = 0 // VersionDev indicates development branch. Releases will be empty string. - VersionDev = "-dev" + VersionDev = "" ) // Version is the specification version that the package types support. diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/.travis.yml b/Godeps/_workspace/src/github.com/opencontainers/specs/.travis.yml deleted file mode 100644 index 5e1b19df..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/.travis.yml +++ /dev/null @@ -1,20 +0,0 @@ -language: go -go: - - 1.5.3 - - 1.4.3 - - 1.3.3 - -sudo: false - -before_install: - - go get golang.org/x/tools/cmd/vet - - go get github.com/golang/lint/golint - - go get github.com/vbatts/git-validation - -install: true - -script: - - go vet -x ./... - - $HOME/gopath/bin/golint ./... - - $HOME/gopath/bin/git-validation -run DCO,short-subject -v -range ${TRAVIS_COMMIT_RANGE} - diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/ChangeLog b/Godeps/_workspace/src/github.com/opencontainers/specs/ChangeLog deleted file mode 100644 index 8c511ad9..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/ChangeLog +++ /dev/null @@ -1,249 +0,0 @@ -OpenContainers Specifications - -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//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 exmaple - * 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 - diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/MAINTAINERS b/Godeps/_workspace/src/github.com/opencontainers/specs/MAINTAINERS deleted file mode 100644 index ac88dd51..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/MAINTAINERS +++ /dev/null @@ -1,9 +0,0 @@ -Michael Crosby (@crosbymichael) -Alexander Morozov (@LK4D4) -Vishnu Kannan (@vishh) -Mrunal Patel (@mrunalp) -Vincent Batts (@vbatts) -Daniel, Dao Quang Minh (@dqminh) -Brandon Philips (@philips) -Tianon Gravi (@tianon) -Qiang Huang (@hqhq) diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/Makefile b/Godeps/_workspace/src/github.com/opencontainers/specs/Makefile deleted file mode 100644 index 224f085c..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/Makefile +++ /dev/null @@ -1,61 +0,0 @@ - -DOCKER ?= $(shell which docker) -DOC_FILES := \ - README.md \ - code-of-conduct.md \ - principles.md \ - style.md \ - ROADMAP.md \ - implementations.md \ - bundle.md \ - runtime.md \ - runtime-linux.md \ - config.md \ - config-linux.md \ - glossary.md -EPOCH_TEST_COMMIT := 041eb73d2e0391463894c04c8ac938036143eba3 - -docs: pdf html -.PHONY: docs - -pdf: - @mkdir -p output/ && \ - $(DOCKER) run \ - -it \ - --rm \ - -v $(shell pwd)/:/input/:ro \ - -v $(shell pwd)/output/:/output/ \ - -u $(shell id -u) \ - vbatts/pandoc -f markdown_github -t latex -o /output/docs.pdf $(patsubst %,/input/%,$(DOC_FILES)) && \ - ls -sh $(shell readlink -f output/docs.pdf) - -html: - @mkdir -p output/ && \ - $(DOCKER) run \ - -it \ - --rm \ - -v $(shell pwd)/:/input/:ro \ - -v $(shell pwd)/output/:/output/ \ - -u $(shell id -u) \ - vbatts/pandoc -f markdown_github -t html5 -o /output/docs.html $(patsubst %,/input/%,$(DOC_FILES)) && \ - ls -sh $(shell readlink -f output/docs.html) - -.PHONY: test .govet .golint .gitvalidation - -test: .govet .golint .gitvalidation - -# `go get golang.org/x/tools/cmd/vet` -.govet: - go vet -x ./... - -# `go get github.com/golang/lint/golint` -.golint: - golint ./... - -# `go get github.com/vbatts/git-validation` -.gitvalidation: - git-validation -q -run DCO,short-subject -v -range $(EPOCH_TEST_COMMIT)..HEAD - -clean: - rm -rf output/ *~ - diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/README.md b/Godeps/_workspace/src/github.com/opencontainers/specs/README.md deleted file mode 100644 index 253a7827..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/README.md +++ /dev/null @@ -1,160 +0,0 @@ -# Open Container Specifications - -[Open Container Initiative](http://www.opencontainers.org/) Specifications for standards on Operating System process and application containers. - - -Table of Contents - -- [Introduction](README.md) - - [Code of Conduct](code-of-conduct.md) - - [Container Principles](principles.md) - - [Style and Conventions](style.md) - - [Roadmap](ROADMAP.md) - - [Implementations](implementations.md) -- [Filesystem Bundle](bundle.md) -- [Runtime and Lifecycle](runtime.md) - - [Linux Specific Runtime](runtime-linux.md) -- Configuration - - [General](config.md) - - [Linux-specific](config-linux.md) -- [Glossary](glossary.md) - -In the specifications in the above table of contents, the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119) (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997). - -# Use Cases - -To provide context for users the following section gives example use cases for each part of the spec. - -#### Application Bundle Builders - -Application bundle builders can create a [bundle](bundle.md) directory that includes all of the files required for launching an application as a container. -The bundle contains an OCI [configuration file](config.md) where the builder can specify host-independent details such as [which executable to launch](config.md#process-configuration) and host-specific settings such as [mount](config.md#mounts) locations, [hook](config.md#hooks) paths, Linux [namespaces](config-linux.md#namespaces) and [cgroups](config-linux.md#control-groups). -Because the configuration includes host-specific settings, application bundle directories copied between two hosts may require configuration adjustments. - -#### Hook Developers - -[Hook](config.md#hooks) developers can extend the functionality of an OCI-compliant runtime by hooking into a container's lifecycle with an external application. -Example use cases include sophisticated network configuration, volume garbage collection, etc. - -#### Runtime Developers - -Runtime developers can build runtime implementations that run OCI-compliant bundles and container configuration, containing low-level OS and host specific details, on a particular platform. - -# Releases - -There is a loose [Road Map](./ROADMAP.md). -During the `0.x` series of OCI releases we make no backwards compatibility guarantees and intend to break the schema during this series. - -# Contributing - -Development happens on GitHub for the spec. -Issues are used for bugs and actionable items and longer discussions can happen on the [mailing list](#mailing-list). - -The specification and code is licensed under the Apache 2.0 license found in the `LICENSE` file of this repository. - -## Code of Conduct - -Participation in the OpenContainers community is governed by [OpenContainer's Code of Conduct](code-of-conduct.md). - -## Discuss your design - -The project welcomes submissions, but please let everyone know what you are working on. - -Before undertaking a nontrivial change to this specification, send mail to the [mailing list](#mailing-list) to discuss what you plan to do. -This gives everyone a chance to validate the design, helps prevent duplication of effort, and ensures that the idea fits. -It also guarantees that the design is sound before code is written; a GitHub pull-request is not the place for high-level discussions. - -Typos and grammatical errors can go straight to a pull-request. -When in doubt, start on the [mailing-list](#mailing-list). - -## Weekly Call - -The contributors and maintainers of the project have a weekly meeting Wednesdays at 10:00 AM PST. -Everyone is welcome to participate via [UberConference web][UberConference] or audio-only: 646-494-8704 (no PIN needed.) -An initial agenda will be posted to the [mailing list](#mailing-list) earlier in the week, and everyone is welcome to propose additional topics or suggest other agenda alterations there. -Minutes are posted to the [mailing list](#mailing-list) and minutes from past calls are archived to the [wiki](https://github.com/opencontainers/specs/wiki) for those who are unable to join the call. - -## Mailing List - -You can subscribe and join the mailing list on [Google Groups](https://groups.google.com/a/opencontainers.org/forum/#!forum/dev). - -## IRC - -OCI discussion happens on #opencontainers on Freenode. - -## Markdown style - -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. - -## Git commit - -### Sign your work - -The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch. -The rules are pretty simple: if you can certify the below (from [developercertificate.org](http://developercertificate.org/)): - -``` -Developer Certificate of Origin -Version 1.1 - -Copyright (C) 2004, 2006 The Linux Foundation and its contributors. -660 York Street, Suite 102, -San Francisco, CA 94110 USA - -Everyone is permitted to copy and distribute verbatim copies of this -license document, but changing it is not allowed. - - -Developer's Certificate of Origin 1.1 - -By making a contribution to this project, I certify that: - -(a) The contribution was created in whole or in part by me and I - have the right to submit it under the open source license - indicated in the file; or - -(b) The contribution is based upon previous work that, to the best - of my knowledge, is covered under an appropriate open source - license and I have the right under that license to submit that - work with modifications, whether created in whole or in part - by me, under the same open source license (unless I am - permitted to submit under a different license), as indicated - in the file; or - -(c) The contribution was provided directly to me by some other - person who certified (a), (b) or (c) and I have not modified - it. - -(d) I understand and agree that this project and the contribution - are public and that a record of the contribution (including all - personal information I submit with it, including my sign-off) is - maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. -``` - -then you just add a line to every git commit message: - - Signed-off-by: Joe Smith - -using your real name (sorry, no pseudonyms or anonymous contributions.) - -You can add the sign off when creating the git commit via `git commit -s`. - -### Commit Style - -Simple house-keeping for clean git history. -Read more on [How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/) or the Discussion section of [`git-commit(1)`](http://git-scm.com/docs/git-commit). - -1. Separate the subject from body with a blank line -2. Limit the subject line to 50 characters -3. Capitalize the subject line -4. Do not end the subject line with a period -5. Use the imperative mood in the subject line -6. Wrap the body at 72 characters -7. Use the body to explain what and why vs. how - * If there was important/useful/essential conversation or information, copy or include a reference -8. When possible, one keyword to scope the change in the subject (i.e. "README: ...", "runtime: ...") - -[UberConference]: https://www.uberconference.com/ssaul diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/ROADMAP.md b/Godeps/_workspace/src/github.com/opencontainers/specs/ROADMAP.md deleted file mode 100644 index 67620ddd..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/ROADMAP.md +++ /dev/null @@ -1,103 +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](https://github.com/opencontainers/specs/wiki/RoadMap:) for collaboration. - -## 1.0 - -### Digest and Hashing - -A bundle is designed to be moved between hosts. -Although OCI doesn't define a transport method we should have a cryptographic digest of the on-disk bundle that can be used to verify that a bundle is not corrupted and in an expected configuration. - -*Owner:* philips - -### Define Container Lifecycle - -Containers have a lifecycle and being able to identify and document the lifecycle of a container is very helpful for implementations of the spec. -The lifecycle events of a container also help identify areas to implement hooks that are portable across various implementations and platforms. - -*Owner:* mrunalp - -### Define Standard Container Actions (Target release: v0.3.0) - -Define what type of actions a runtime can perform on a container without imposing hardships on authors of platforms that do not support advanced options. - -*Owner:* duglin - -### 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 - -### Live Container Updates - -Should we allow dynamic container updates to runtime options? - -Proposal: make it an optional feature - -*Owner:* hqhq (was vishh) robdolinms, bcorrie - -### Validation Tooling (Target release: v0.3.0) - -Provide validation tooling for compliance with OCI spec and runtime environment. - -*Owner:* mrunalp - -### Testing Framework - -Provide a testing framework for compliance with OCI spec and runtime environment. - -*Owner:* liangchenye - -### 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 - -### Printable/Compiled Spec - -Regardless of how the spec is written, ensure that it is easy to read and follow for first time users. - -Part of this is resolved. Produces an html & pdf. -Done -Would be nice to publish to the OCI web site as part of our release process. - -*Owner:* vbatts - -### Base Config Compatibility - -Ensure that the base configuration format is viable for various platforms. - -Systems: - -* Solaris -* Windows -* Linux - -*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:* - -### Distributable Format - -A common format for serializing and distributing bundles. - -*Owner:* vbatts diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/bundle.md b/Godeps/_workspace/src/github.com/opencontainers/specs/bundle.md deleted file mode 100644 index 5b1925b2..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/bundle.md +++ /dev/null @@ -1,24 +0,0 @@ -# Filesystem Bundle - -## 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 [OS X application bundles](http://en.wikipedia.org/wiki/Bundle_%28OS_X%29) 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 file system 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 includes the following artifacts which MUST all reside in the same directory on the local filesystem: - -1. `config.json` : contains configuration data. -This REQUIRED file, which MUST be named `config.json`. -When the bundle is packaged up for distribution, this file MUST be included. -See [`config.json`](config.md) for more details. - -2. 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`. -When the bundle is packaged up for distribution, this directory MUST be included. -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. diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/code-of-conduct.md b/Godeps/_workspace/src/github.com/opencontainers/specs/code-of-conduct.md deleted file mode 100644 index 06cb2b83..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/code-of-conduct.md +++ /dev/null @@ -1,37 +0,0 @@ -# OpenContainers Code of Conduct - -Behave as a community member, follow the code of conduct. - -## Code of Conduct - -The OpenContainers community is made up of a mixture of professionals and volunteers from all over the world. - -When we disagree, we try to understand why. -Disagreements, both social and technical, happen all the time and OpenContainers is no exception. -It is important that we resolve disagreements and differing views constructively. - -This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. -Participants should be aware of these concerns. - -We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality. - -Examples of unacceptable behavior by participants include: - -* The use of sexualized language or imagery -* Personal attacks -* Trolling or insulting/derogatory comments -* Public or private harassment -* Publishing other's private information, such as physical or electronic addresses, without explicit permission -* Other unethical or unprofessional conduct - -The OpenContainers team does not condone any statements by speakers contrary to these standards. -The OpenContainers team reserves the right to deny participation any individual found to be engaging in discriminatory or harassing actions. - -Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. -By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. - -## Thanks - -Thanks to the [Fedora Code of Conduct](https://getfedora.org/code-of-conduct) and [Contributor Covenant](http://contributor-covenant.org) for inspiration and ideas. - -Portions of this Code of Conduct are adapted from the Contributor Covenant, version 1.2.0, available at http://contributor-covenant.org/version/1/2/0/ diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/config-linux.md b/Godeps/_workspace/src/github.com/opencontainers/specs/config-linux.md deleted file mode 100644 index 5e77c113..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/config-linux.md +++ /dev/null @@ -1,545 +0,0 @@ -# Linux-specific Container Configuration - -The Linux container specification uses various kernel features like namespaces, cgroups, capabilities, LSM, and file system jails to fulfill the spec. -Additional information is needed for Linux over the [default spec configuration](config.md) in order to configure these various kernel features. - -## Default File Systems - -The Linux ABI includes both syscalls and several special file paths. -Applications expecting a Linux environment will very likely expect these files paths to be setup correctly. - -The following filesystems MUST be made available in each application's filesystem - -| Path | Type | -| -------- | ------ | -| /proc | [procfs](https://www.kernel.org/doc/Documentation/filesystems/proc.txt) | -| /sys | [sysfs](https://www.kernel.org/doc/Documentation/filesystems/sysfs.txt) | -| /dev/pts | [devpts](https://www.kernel.org/doc/Documentation/filesystems/devpts.txt) | -| /dev/shm | [tmpfs](https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt) | - -## 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 man page](http://man7.org/linux/man-pages/man7/namespaces.7.html). - -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 namespaces 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 - -* **`path`** *(string, optional)* - path to namespace file - -If a path is specified, that particular file is used to join that type of namespace. -Also, when a path is specified, a runtime MUST assume that the setup for that particular namespace has already been done and error out if the config specifies anything else related to that namespace. - -###### 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" - } - ] -``` - -## User namespace mappings - -###### Example - -```json - "uidMappings": [ - { - "hostID": 1000, - "containerID": 0, - "size": 10 - } - ], - "gidMappings": [ - { - "hostID": 1000, - "containerID": 0, - "size": 10 - } - ] -``` - -uid/gid mappings describe the user namespace mappings from the host to the container. -The mappings represent how the bundle `rootfs` expects the user namespace to be setup and the runtime SHOULD NOT modify the permissions on the rootfs to realize the mapping. -*hostID* is the starting uid/gid on the host to be mapped to *containerID* which is the starting uid/gid in the container and *size* refers to the number of ids to be mapped. -There is a limit of 5 mappings which is the Linux kernel hard limit. - -## Devices - -`devices` is an array specifying the list of 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.). - -The following parameters can be specified: - -* **`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. -* **`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. - -###### 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 - } - ] -``` - -###### 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] -* [`/dev/ptmx`][pts.4]. - A [bind-mount or symlink of the container's `/dev/pts/ptmx`][devpts]. - -## Control groups - -Also known as cgroups, they are used to restrict resource usage for a container and handle device access. -cgroups provide controls 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` is expected to be relative to the cgroups mount point. -If `cgroupsPath` is not specified, implementations can define the default cgroup path. -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 [split hierarchy][cgroup-v2]. -The cgroups will be created if they don't exist. - -###### Example - -```json - "cgroupsPath": "/myRuntime/myContainer" -``` - -`cgroupsPath` can be used to either control the cgroups hierarchy for containers or to run a new process in an existing container. - -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. - -#### Device whitelist - -`devices` is an array of entries to control the [device whitelist][cgroup-v1-devices]. -The runtime MUST apply entries in the listed order. - -The following parameters can be specified: - -* **`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" - } - ] -``` - -#### 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 -``` - -#### 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](https://www.kernel.org/doc/Documentation/filesystems/proc.txt). -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": 0 -``` - -#### Memory - -`memory` 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 - -* **`reservation`** *(uint64, optional)* - sets soft limit of memory usage - -* **`swap`** *(uint64, optional)* - sets limit of memory+Swap usage - -* **`kernel`** *(uint64, optional)* - sets hard limit for kernel memory - -* **`kernelTCP`** *(uint64, optional)* - sets hard limit for kernel memory in tcp using - -* **`swappiness`** *(uint64, optional)* - sets swappiness parameter of vmscan (See sysctl's vm.swappiness) - -###### Example - -```json - "memory": { - "limit": 0, - "reservation": 0, - "swap": 0, - "kernel": 0, - "kernelTCP": 0, - "swappiness": 0 - } -``` - -#### CPU - -`cpu` 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`** *(uint64, 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`** *(uint64, 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": 0, - "quota": 0, - "period": 0, - "realtimeRuntime": 0, - "realtimePeriod": 0, - "cpus": "", - "mems": "" - } -``` - -#### Block IO Controller - -`blockIO` 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": 0, - "blkioLeafWeight": 0, - "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 - } - ] - } -``` - -#### Huge page limits - -`hugepageLimits` 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]. - -`hugepageLimits` is an array of entries, each having the following structure: - -* **`pageSize`** *(string, required)* - hugepage size - -* **`limit`** *(uint64, required)* - limit in bytes of *hugepagesize* HugeTLB usage - -###### Example - -```json - "hugepageLimits": [ - { - "pageSize": "2MB", - "limit": 9223372036854771712 - } - ] -``` - -#### Network - -`network` 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 these cgroup controllers: - -* **`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 - } - ] - } -``` - -#### PIDs - -`pids` represents the cgroup subsystem `pids`. -For more information, see [the pids cgroup man page][cgroup-v1-pids]. - -The following paramters can be specified to setup the controller: - -* **`limit`** *(int64, required)* - specifies the maximum number of tasks in the cgroup - -###### Example - -```json - "pids": { - "limit": 32771 - } -``` - -## Sysctl - -sysctl allows kernel parameters to be modified at runtime for the container. -For more information, see [the man page](http://man7.org/linux/man-pages/man8/sysctl.8.html) - -###### Example - -```json - "sysctl": { - "net.ipv4.ip_forward": "1", - "net.core.somaxconn": "256" - } -``` - -## 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 kernel documentation](https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt) -The actions, architectures, and operators are strings that match the definitions in seccomp.h from [libseccomp](https://github.com/seccomp/libseccomp) and are translated to corresponding values. -A valid list of constants as of Libseccomp v2.2.3 is contained 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` - -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" - ], - "syscalls": [ - { - "name": "getcwd", - "action": "SCMP_ACT_ERRNO" - } - ] - } -``` - -## Rootfs Mount Propagation - -rootfsPropagation sets the rootfs's mount propagation. -Its value is either slave, private, or shared. -[The kernel doc](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) has more information about mount propagation. - -###### Example - -```json - "rootfsPropagation": "slave", -``` - -[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 - -[mknod.1]: http://man7.org/linux/man-pages/man1/mknod.1.html -[mknod.2]: http://man7.org/linux/man-pages/man2/mknod.2.html -[console.4]: http://man7.org/linux/man-pages/man4/console.4.html -[full.4]: http://man7.org/linux/man-pages/man4/full.4.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 -[tty.4]: http://man7.org/linux/man-pages/man4/tty.4.html -[zero.4]: http://man7.org/linux/man-pages/man4/zero.4.html diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/config.md b/Godeps/_workspace/src/github.com/opencontainers/specs/config.md deleted file mode 100644 index a832bdde..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/config.md +++ /dev/null @@ -1,428 +0,0 @@ -# Container Configuration file - -The container's top-level directory MUST contain a configuration file called `config.json`. -For now the canonical schema is defined in [config.go](config.go) and [config_linux.go](config_linux.go), but this will be moved to a formal JSON schema over time. - -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. - -## Specification version - -* **`ociVersion`** (string, required) must be in [SemVer v2.0.0](http://semver.org/spec/v2.0.0.html) format and specifies the version of the OpenContainer specification with which the bundle complies. -The OpenContainer spec follows semantic versioning and retains forward and backward compatibility within major versions. -For example, if an implementation is compliant with version 1.0.1 of the spec, it is compatible with the complete 1.x series. -NOTE that there is no guarantee for forward or backward compatibility for version 0.x. - -*Example* - -```json - "ociVersion": "0.1.0" -``` - -## Root Configuration - -Each container has exactly one *root filesystem*, specified in the *root* object: - -* **`path`** (string, required) Specifies the path to the root filesystem for the container, relative to the path where the manifest is. A directory MUST exist at the relative 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 -} -``` - -## Mounts - -You can add array of mount points inside container as `mounts`. -The runtime MUST mount entries in the listed order. -The parameters are similar to the ones in [the Linux mount system call](http://man7.org/linux/man-pages/man2/mount.2.html). - -* **`destination`** (string, required) Destination of mount point: path inside container. -* **`type`** (string, required) Linux, *filesystemtype* argument supported by the kernel are listed in */proc/filesystems* (e.g., "minix", "ext2", "ext3", "jfs", "xfs", "reiserfs", "msdos", "proc", "nfs", "iso9660"). Windows: ntfs -* **`source`** (string, required) 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) -* **`options`** (list of strings, optional) in the fstab format [https://wiki.archlinux.org/index.php/Fstab](https://wiki.archlinux.org/index.php/Fstab). - -### Linux Example - -```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"] - } -] -``` - -### Windows Example - -```json -"mounts": [ - "myfancymountpoint": { - "destination": "C:\\Users\\crosbymichael\\My Fancy Mount Point\\", - "type": "ntfs", - "source": "\\\\?\\Volume\\{2eca078d-5cbc-43d3-aff8-7e8511f60d0e}\\", - "options": [] - } -] -``` - -See links for details about [mountvol](http://ss64.com/nt/mountvol.html) and [SetVolumeMountPoint](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365561(v=vs.85).aspx) in Windows. - - -## Process configuration - -* **`terminal`** (bool, optional) specifies whether you want a terminal attached to that process. Defaults to false. -* **`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) contains a list of variables that will be set in the process's environment prior to execution. Elements in the array are specified as Strings in the form "KEY=value". The left hand side must consist solely of letters, digits, and underscores `_` as outlined in [IEEE Std 1003.1-2001](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html). -* **`args`** (string, required) executable to launch and any flags as an array. The executable is the first element and must be available at the given path inside of the rootfs. If the executable path is not an absolute path then the search $PATH is interpreted to find the executable. - -For Linux-based systems the process structure supports the following process specific fields: - -* **`capabilities`** (array of strings, optional) capabilities is an array that specifies Linux capabilities that can be provided to the process inside the container. -Valid values are the strings for capabilities defined in [the man page](http://man7.org/linux/man-pages/man7/capabilities.7.html) -* **`rlimits`** (array of rlimits, optional) rlimits is an array of rlimits that allows setting resource limits for a process inside the container. -The kernel enforces the `soft` limit for a resource while the `hard` limit acts as a ceiling for that value that could be set by an unprivileged process. -Valid values for the 'type' field are the resources defined in [the man page](http://man7.org/linux/man-pages/man2/setrlimit.2.html). -* **`apparmorProfile`** (string, optional) apparmor profile specifies the name of the apparmor profile that will be used for the container. -For more information about Apparmor, see [Apparmor documentation](https://wiki.ubuntu.com/AppArmor) -* **`selinuxLabel`** (string, optional) SELinux process label specifies the label with which the processes in a container are run. -For more information about SELinux, see [Selinux documentation](http://selinuxproject.org/page/Main_Page) -* **`noNewPrivileges`** (bool, optional) setting `noNewPrivileges` to true prevents the processes in the container from gaining additional privileges. -[The kernel doc](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) has more information on how this is achieved using a prctl system call. - -The user for the process is a platform-specific structure that allows specific control over which user the process runs as. -For Linux-based systems the user structure has the following fields: - -* **`uid`** (int, required) specifies the user id. -* **`gid`** (int, required) specifies the group id. -* **`additionalGids`** (array of ints, optional) specifies additional group ids to be added to the process. - -*Example (Linux)* - -```json -"process": { - "terminal": true, - "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": [ - "CAP_AUDIT_WRITE", - "CAP_KILL", - "CAP_NET_BIND_SERVICE" - ], - "rlimits": [ - { - "type": "RLIMIT_NOFILE", - "hard": 1024, - "soft": 1024 - } - ] -} -``` - - -## Hostname - -* **`hostname`** (string, optional) as it is accessible to processes running inside. On Linux, you can only set this if your bundle creates a new [UTS namespace][uts-namespace]. - -*Example* - -```json -"hostname": "mrsdalloway" -``` - -## Platform-specific configuration - -* **`os`** (string, required) specifies the operating system family this image must run on. Values for os must be in the list specified by the Go Language document for [`$GOOS`](https://golang.org/doc/install/source#environment). -* **`arch`** (string, required) specifies the instruction set for which the binaries in the image have been compiled. Values for arch must be in the list specified by the Go Language document for [`$GOARCH`](https://golang.org/doc/install/source#environment). - -```json -"platform": { - "os": "linux", - "arch": "amd64" -} -``` - -Interpretation of the platform section of the JSON file is used to find which platform-specific sections may be available in the document. -For example, if `os` is set to `linux`, then a JSON object conforming to the [Linux-specific schema](config-linux.md) SHOULD be found at the key `linux` in the `config.json`. - -## Hooks - -Lifecycle hooks allow custom events for different points in a container's runtime. -Presently there are `Prestart`, `Poststart` and `Poststop`. - -* [`Prestart`](#prestart) is a list of hooks to be run before the container process is executed -* [`Poststart`](#poststart) is a list of hooks to be run immediately after the container process is started -* [`Poststop`](#poststop) is a list of hooks to be run after the container process exits - -Hooks allow one to run code before/after various lifecycle events of the container. -Hooks MUST be called in the listed order. -The state of the container is passed to the hooks over stdin, so the hooks could get the information they need to do their work. - -Hook paths are absolute and are executed from the host's filesystem. - -### Prestart - -The pre-start hooks are called after the container process is spawned, but before the user supplied command is executed. -They are called after the container namespaces are created on Linux, so they provide an opportunity to customize the container. -In Linux, for e.g., the network namespace could be configured in this hook. - -If a hook returns a non-zero exit code, then an error including the exit code and the stderr is returned to the caller and the container is torn down. - -### Poststart - -The post-start hooks are called after the user process is started. -For example this hook can notify user that real process is spawned. - -If a hook returns a non-zero exit code, then an error is logged and the remaining hooks are executed. - -### Poststop - -The post-stop hooks are called after the container process is stopped. -Cleanup or debugging could be performed in such a hook. -If a hook returns a non-zero exit code, then an error is logged and the remaining hooks are executed. - -*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" - } - ], - "poststop": [ - { - "path": "/usr/sbin/cleanup.sh", - "args": ["cleanup.sh", "-f"] - } - ] - } -``` - -`path` is required for a hook. -`args` and `env` are optional. -The semantics are the same as `Path`, `Args` and `Env` in [golang Cmd](https://golang.org/pkg/os/exec/#Cmd). - -## Annotations - -Annotations are optional arbitrary non-identifying metadata that can be attached to containers. -This information may be large, may be structured or unstructured. -Annotations are key-value maps. - -```json -"annotations": { - "key1" : "value1", - "key2" : "value2" -} -``` - -## Configuration Schema Example - -Here is a full example `config.json` for reference. - -```json -{ - "ociVersion": "0.3.0", - "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": [ - "CAP_AUDIT_WRITE", - "CAP_KILL", - "CAP_NET_BIND_SERVICE" - ], - "rlimits": [ - { - "type": "RLIMIT_NOFILE", - "hard": 1024, - "soft": 1024 - } - ], - "apparmorProfile": "", - "selinuxLabel": "" - }, - "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/uptime", - "args": [ - "/usr/bin/uptime" - ], - "env": [] - } - ] - }, - "linux": { - "resources": { - "devices": [ - { - "allow": false, - "access": "rwm" - } - ] - }, - "namespaces": [ - { - "type": "pid" - }, - { - "type": "network" - }, - { - "type": "ipc" - }, - { - "type": "uts" - }, - { - "type": "mount" - } - ], - "devices": null, - "seccomp": { - "defaultAction": "", - "architectures": null - } - } -} -``` - - -[uts-namespace]: http://man7.org/linux/man-pages/man7/namespaces.7.html diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/glossary.md b/Godeps/_workspace/src/github.com/opencontainers/specs/glossary.md deleted file mode 100644 index f9d11c4f..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/glossary.md +++ /dev/null @@ -1,26 +0,0 @@ -# Glossary - -## 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. - -## Configuration - -The [`config.json`](config.md) file in a [bundle](#bundle) which defines the intended [container](#container) and container process. - -## 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. - -## JSON - -All configuration [JSON][] MUST be encoded in [UTF-8][]. - -## 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). - -[JSON]: http://json.org/ -[UTF-8]: http://www.unicode.org/versions/Unicode8.0.0/ch03.pdf diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/implementations.md b/Godeps/_workspace/src/github.com/opencontainers/specs/implementations.md deleted file mode 100644 index 5cd16b98..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/implementations.md +++ /dev/null @@ -1,21 +0,0 @@ -# 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. - -## Runtime (Container) - -* [opencontainers/runc](https://github.com/opencontainers/runc) - Reference implementation of OCI runtime - -## Runtime (Virtual Machine) - -* [hyperhq/runv](https://github.com/hyperhq/runv) - Hypervisor-based runtime for OCI - -## Bundle authoring - -* [kunalkushwaha/octool](https://github.com/kunalkushwaha/octool) - A config linter and validator. -* [mrunalp/ocitools](https://github.com/mrunalp/ocitools) - A config generator. - -## Testing - -* [huawei-openlab/oct](https://github.com/huawei-openlab/oct) - Open Container Testing framework for OCI configuration and runtime diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/principles.md b/Godeps/_workspace/src/github.com/opencontainers/specs/principles.md deleted file mode 100644 index 5dbab169..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/principles.md +++ /dev/null @@ -1,46 +0,0 @@ -# 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. - -## 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. - -## 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. - -## 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. - -## 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. - -## 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. diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/project.md b/Godeps/_workspace/src/github.com/opencontainers/specs/project.md deleted file mode 100644 index 30bce26b..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/project.md +++ /dev/null @@ -1,10 +0,0 @@ -# Project docs - -## Release Process - -* Increment version in version.go -* `git commit` version increment -* `git tag` the prior commit (preferrably signed tag) -* `make docs` to produce PDF and HTML copies of the spec -* Make a release on [github.com/opencontainers/specs](https://github.com/opencontainers/specs/releases) for the version. Attach the produced docs. - diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/runtime-linux.md b/Godeps/_workspace/src/github.com/opencontainers/specs/runtime-linux.md deleted file mode 100644 index 36277a19..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/runtime-linux.md +++ /dev/null @@ -1,8 +0,0 @@ -# Linux Runtime - -## 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](http://0pointer.de/blog/projects/socket-activated-containers.html). - -Some of the file descriptors may be redirected to `/dev/null` even though they are open. diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/runtime.md b/Godeps/_workspace/src/github.com/opencontainers/specs/runtime.md deleted file mode 100644 index 47d4adda..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/runtime.md +++ /dev/null @@ -1,129 +0,0 @@ -# Runtime and Lifecycle - -## 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. - -## State - -The state of a container MUST include, at least, the following propeties: - -* **`ociVersion`**: (string) is the OCI specification version used when creating the container. -* **`id`**: (string) 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. -The ID is provided in the state because hooks will be executed with the state as the payload. -This allows the hooks to perform cleanup and teardown logic after the runtime destroys its own state. -* **`pid`**: (int) is the ID of the main process within the container, as seen by the host. -* **`bundlePath`**: (string) 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. - -When serialized in JSON, the format MUST adhere to the following pattern: -```json -{ - "ociVersion": "0.2.0", - "id": "oci-container1", - "pid": 4422, - "bundlePath": "/containers/redis" -} -``` - -See [Query State](#query-state) for information on retrieving the state of a container. - -## 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 is invoked with a reference to the location of the bundle. - How this reference is passed to the runtime is an implementation detail. -2. The container's runtime environment MUST be created according to the configuration in [`config.json`](config.md). - Any updates to `config.json` after container is running MUST not affect the container. -3. The prestart hooks MUST be invoked by the runtime. - If any prestart hook fails, then the container MUST be stopped and the lifecycle continues at step 8. -4. The user specified process MUST be executed in the container. -5. The poststart hooks MUST be invoked by the runtime. - If any poststart hook fails, then the container MUST be stopped and the lifecycle continues at step 8. -6. Additional actions such as pausing the container, resuming the container or signaling the container MAY be performed using the runtime interface. - The container MAY also error out, exit or crash. -7. The container MUST be destroyed by undoing the steps performed during create phase (step 2). -8. The poststop hooks MUST be invoked by the runtime and errors, if any, MAY be logged. - -Note: The lifecycle is a WIP and it will evolve as we have more use cases and more information on the viability of a separate create phase. - -## Operations - -OCI compliant runtimes MUST support the following operations, unless the operation is not supported by the base operating system. - -### 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. - -### Query State - -`state ` - -This operation MUST generate an error if it is not provided the ID of a container. -This operation MUST return the state of a container as specified in the [State](#state) section. -In particular, the state MUST be serialized as JSON. - - -### Start - -`start ` - -This operation MUST generate an error 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. -Using the data in `config.json`, that are in the bundle's directory, this operation MUST create a new container. -This includes creating the relevant namespaces, resource limits, etc and configuring the appropriate capabilities for the container. -A new process within the scope of the container MUST be created as specified by the `config.json` file otherwise an error MUST be generated. - -Attempting to start an already running container MUST have no effect on the container and MUST generate an error. - -### Stop - -`stop ` - -This operation MUST generate an error if it is not provided the container ID. -This operation MUST stop and delete a running container. -Stopping a container MUST stop all of the processes running within the scope of the container. -Deleting a container MUST delete the associated namespaces and resources associated with the container. -Once a container is deleted, its `id` MAY be used by subsequent containers. -Attempting to stop a container that is not running MUST have no effect on the container and MUST generate an error. - -### Exec - -`exec ` - -This operation MUST generate an error if it is not provided the container ID and a path to the JSON describing the process to start. -The JSON describing the new process MUST adhere to the [Process configuration](config.md#process-configuration) definition. -This operation MUST create a new process within the scope of the container. -If the container is not running then this operation MUST have no effect on the container and MUST generate an error. -Executing this operation multiple times MUST result in a new process each time. -Example: -``` -{ - "terminal": true, - "user": { - "uid": 0, - "gid": 0, - "additionalGids": null - }, - "args": [ - "/bin/sleep", - "60" - ], - "env": [ - "version=1.0" - ], - "cwd": "...", -} -``` -This specification does not manadate the name of this JSON file. -See the specification of the `config.json` file for the definition of these fields. -The stopping, or exiting, of these secondary process MUST have no effect on the state of the container. -In other words, a container (and its PID 1 process) MUST NOT be stopped due to the exiting of a secondary process. - -## 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. diff --git a/Godeps/_workspace/src/github.com/opencontainers/specs/style.md b/Godeps/_workspace/src/github.com/opencontainers/specs/style.md deleted file mode 100644 index a04b6ba5..00000000 --- a/Godeps/_workspace/src/github.com/opencontainers/specs/style.md +++ /dev/null @@ -1,26 +0,0 @@ -# Style and conventions - -## 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]). - -## 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]). - -## Optional settings should have pointer Go types - -So we have a consistent way to identify unset values ([source][optional-pointer]). -The exceptions are entries where the Go default for the type is a no-op in the spec, in which case `omitempty` is sufficient and no pointer is needed (sources [here][no-pointer-for-slices], [here][no-pointer-for-boolean], and [here][pointer-when-updates-require-changes]). - - -[capabilities]: config-linux.md#capabilities -[class-id]: config-linux.md#network -[integer-over-hex]: https://github.com/opencontainers/specs/pull/267#discussion_r48360013 -[keep-prefix]: https://github.com/opencontainers/specs/pull/159#issuecomment-138728337 -[no-pointer-for-boolean]: https://github.com/opencontainers/specs/pull/290#discussion_r50296396 -[no-pointer-for-slices]: https://github.com/opencontainers/specs/pull/316/files#r50782982 -[optional-pointer]: https://github.com/opencontainers/specs/pull/233#discussion_r47829711 -[pointer-when-updates-require-changes]: https://github.com/opencontainers/specs/pull/317/files#r50932706 diff --git a/README.md b/README.md index 3b407540..1e6e503a 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ the spec is finalized. However, we encourage you to try out the tool and give fe How does `runc` integrate with the Open Container Initiative Specification? `runc` depends on the types specified in the -[specs](https://github.com/opencontainers/specs) repository. Whenever the +[specs](https://github.com/opencontainers/runtime-spec) repository. Whenever the specification is updated and ready to be versioned `runc` will update its dependency on the specs repository and support the update spec. @@ -79,7 +79,7 @@ PID USER COMMAND ### OCI Container JSON Format: -OCI container JSON format is based on OCI [specs](https://github.com/opencontainers/specs). +OCI container JSON format is based on OCI [specs](https://github.com/opencontainers/runtime-spec). You can generate JSON files by using `runc spec`. It assumes that the file-system is found in a directory called `rootfs` and there is a user with uid and gid of `0` defined within that file-system. diff --git a/exec.go b/exec.go index 1ee6cd81..76525886 100644 --- a/exec.go +++ b/exec.go @@ -11,7 +11,7 @@ import ( "github.com/codegangsta/cli" "github.com/opencontainers/runc/libcontainer/utils" - "github.com/opencontainers/specs/specs-go" + "github.com/opencontainers/runtime-spec/specs-go" ) var execCommand = cli.Command{ diff --git a/libcontainer/specconv/spec_linux.go b/libcontainer/specconv/spec_linux.go index b490eb42..248c15a6 100644 --- a/libcontainer/specconv/spec_linux.go +++ b/libcontainer/specconv/spec_linux.go @@ -17,7 +17,7 @@ import ( "github.com/opencontainers/runc/libcontainer/configs" "github.com/opencontainers/runc/libcontainer/seccomp" libcontainerUtils "github.com/opencontainers/runc/libcontainer/utils" - "github.com/opencontainers/specs/specs-go" + "github.com/opencontainers/runtime-spec/specs-go" ) const wildcard = -1 diff --git a/libcontainer/specconv/spec_linux_test.go b/libcontainer/specconv/spec_linux_test.go index 42c6042b..da842057 100644 --- a/libcontainer/specconv/spec_linux_test.go +++ b/libcontainer/specconv/spec_linux_test.go @@ -6,7 +6,7 @@ import ( "strings" "testing" - "github.com/opencontainers/specs/specs-go" + "github.com/opencontainers/runtime-spec/specs-go" ) func TestLinuxCgroupsPathSpecified(t *testing.T) { diff --git a/main.go b/main.go index 4c25ba82..fba98b65 100644 --- a/main.go +++ b/main.go @@ -7,7 +7,7 @@ import ( "github.com/Sirupsen/logrus" "github.com/codegangsta/cli" - "github.com/opencontainers/specs/specs-go" + "github.com/opencontainers/runtime-spec/specs-go" ) // gitCommit will be the hash that the binary was built from @@ -15,7 +15,7 @@ import ( var gitCommit = "" const ( - version = "0.0.9" + version = "0.1.0" specConfig = "config.json" usage = `Open Container Initiative runtime diff --git a/restore.go b/restore.go index f015e666..13f3b6d2 100644 --- a/restore.go +++ b/restore.go @@ -11,7 +11,7 @@ import ( "github.com/opencontainers/runc/libcontainer" "github.com/opencontainers/runc/libcontainer/configs" "github.com/opencontainers/runc/libcontainer/specconv" - "github.com/opencontainers/specs/specs-go" + "github.com/opencontainers/runtime-spec/specs-go" ) var restoreCommand = cli.Command{ diff --git a/spec.go b/spec.go index 9ca85cdf..69ea1e50 100644 --- a/spec.go +++ b/spec.go @@ -11,7 +11,7 @@ import ( "github.com/codegangsta/cli" "github.com/opencontainers/runc/libcontainer/configs" - "github.com/opencontainers/specs/specs-go" + "github.com/opencontainers/runtime-spec/specs-go" ) var specCommand = cli.Command{ diff --git a/start.go b/start.go index b0d50ecf..dcdcb324 100644 --- a/start.go +++ b/start.go @@ -9,7 +9,7 @@ import ( "github.com/codegangsta/cli" "github.com/coreos/go-systemd/activation" "github.com/opencontainers/runc/libcontainer" - "github.com/opencontainers/specs/specs-go" + "github.com/opencontainers/runtime-spec/specs-go" ) // default action is to start a container diff --git a/state.go b/state.go index 89517046..50cb5d95 100644 --- a/state.go +++ b/state.go @@ -13,7 +13,7 @@ import ( // cState represents the platform agnostic pieces relating to a running // container's status and state. Note: The fields in this structure adhere to -// the opencontainers/specs/specs-go requirement for json fields that must be returned +// the opencontainers/runtime-spec/specs-go requirement for json fields that must be returned // in a state command. type cState struct { // Version is the OCI version for the container diff --git a/utils.go b/utils.go index 55bb7361..d4986a0c 100644 --- a/utils.go +++ b/utils.go @@ -14,7 +14,7 @@ import ( "github.com/opencontainers/runc/libcontainer" "github.com/opencontainers/runc/libcontainer/cgroups/systemd" "github.com/opencontainers/runc/libcontainer/specconv" - "github.com/opencontainers/specs/specs-go" + "github.com/opencontainers/runtime-spec/specs-go" ) var errEmptyID = errors.New("container id cannot be empty")