So that the semantics of the tags are clear.
The platform/protocol disconnect is unfortunate. "Protocol" was
chosen in de3f1af6 (Remove language around Solaris being optional as
it is covered in compliance language, 2016-08-17, #527) because we may
have compliance subsets that aren't linked to platforms [1]. I'd be
open to renaming the JSON tag from platform:"..." -> protocol:"...",
but that's probably more change than it's worth. The approach taken
in this commit, on the other hand, renames "protocol" to "platform".
I think that unnecessarily limits (or sets up confusing semantics for)
the platform/protocol values you can use, but two maintainers both
prefer "platform" [2,3].
[1]: https://github.com/opencontainers/runtime-spec/pull/527#issuecomment-238979250
[2]: https://github.com/opencontainers/runtime-spec/pull/570#discussion_r99227202
[3]: https://github.com/opencontainers/runtime-spec/pull/570#discussion_r100013014
Signed-off-by: W. Trevor King <wking@tremily.us>
We'll be referring to these in code, and using a slug everywhere
avoids having to define both a slug form (linux) and an English form
(Linux containers).
Signed-off-by: W. Trevor King <wking@tremily.us>
this commit contains:
* add explicit usage message to validate
* schemaPath was overrided by filepath.Abs(), schemaLoader would not get
* the abs path.
* check local scheme and document file path with os.Stat()
Signed-off-by: Deng Guangxing <dengguangxing@huawei.com>
Maintainers feel (and I agree) that there's no point in explicitly
allowing a null value when callers can simply leave the property unset
[1]. This commit removes all references to "pointer" and "null" from
the JSON Schema to support that decision. While optional properties
may sometimes be represented as pointer types in Go [2], optional
properties should be represented in JSON Schema by not including the
properties in the 'required' array.
[1]: https://github.com/opencontainers/runtime-spec/pull/555#issuecomment-272020515
[2]: style.md "Optional settings should not have pointer Go types"
Signed-off-by: W. Trevor King <wking@tremily.us>
To distinguish between "we're still setting this container up" and
"we're finished setting up; you can call 'start' if you like".
Also reference the lifecycle steps, because you can't be too explicit
Signed-off-by: W. Trevor King <wking@tremily.us>
Because during creation (before 'created') we may not have a container
process yet (e.g. if we're still reading the configuration or setting
up cgroups), and in the 'stopped' phase the PID is no longer
meaningful.
Also add OPTIONAL/REQUIRED and remove colons for consistency with the
config.md.
Signed-off-by: W. Trevor King <wking@tremily.us>
Work around travis-ci/travis-ci#4596 until that is fixed upstream [1].
This avoids pulling in commits from the base tip that aren't reachable
from the head tip (e.g. if master has advanced since the PR branched
off, and the PR is against master). We only want to check commits
that are in the head branch but not in the base branch (more details
on the range syntax in [2]).
Once the Travis bug does get fixed, the shell replacement will be a
no-op. So we don't have to worry about checks breaking once the bug
gets fixed, and can periodically poll the bug and remove the
workaround at out leisure after the fix.
[1]: https://github.com/travis-ci/travis-ci/issues/4596
[2]: http://git-scm.com/docs/gitrevisions#_specifying_ranges
Signed-off-by: W. Trevor King <wking@tremily.us>
Mrunal Patel
Michael Crosby
Ma Shimiao
Vincent Batts
W. Trevor King
Deng Guangxing
Jesse Butler
Qiang Huang
Daniel Dao
Rob Dolin (MSFT)