If we don't specify this, some bundle-authors or runtime-implementers
might expect the runtime to intelligently order mounts to get the
"right" order [1]. But that's not possible because:
$ mkdir -p a/b/c d/e/f h
# mount --bind a/b h
# mount --bind d a/b
$ tree --charset=ascii h
h
`-- c
But in the other order:
# umount a/b
# umount h
# mount --bind d a/b
# mount --bind a/b h
$ tree --charset=ascii h
h
`-- e
`-- f
So there's no "right" order. Allowing the bundle-author to specify
their intended order is both easy to implement and unambiguous.
[1]: https://github.com/opencontainers/specs/pull/136#issuecomment-137275876
Suggested-by: Lai Jiangshan <jiangshanlai@gmail.com>
Signed-off-by: W. Trevor King <wking@tremily.us>
Accomplishing the same access to the commit entry, with more readable
code.
Reported-by: Lai Jiangshan <jiangshanlai@gmail.com>
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Initially only a DCO validation for travis, but is set up for further
validation on commits as well.
https://github.com/opencontainers/specs/issues/90
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
c18c283 (Change layout of mountpoints and mounts, 2015-09-02, #136)
removed the destination field from the Go type and examples, but
forgot to remove it from the documentation [1]. Fix that with this
commit.
[1]: https://github.com/opencontainers/specs/issues/109#issuecomment-138531616
Reported-by: 梁辰晔 (Liang Chenye) <liangchenye@huawei.com>
Signed-off-by: W. Trevor King <wking@tremily.us>
There are two RootfsPropagation fields, one is Linux.RootfsPropagation,
the other one is LinuxRuntime.RootfsPropagation. They are duplicated,
one of them should be removed.
The RootfsPropagation is definitely a runtime specific configuration,
so we remove the one of Linux.RootfsPropagation.
And the description of it is moved from config-linux.md to
runtime-config-linux.md.
Signed-off-by: Lai Jiangshan <jiangshanlai@gmail.com>
In an effort to be more discoverable and self-describing change out the
term "oci" for "opencontainer". We should consider using this as the
prefix for global namespaces going forward as oc has conflicts with
existing tools and oci is the name of the initiative not the specs.
Add support for the PIDs cgroup as a cgroup resource constraint in the
Linux container specification. Since PIDs are a real resource, we need
to support the ability to limit them.
The PIDs cgroup subsystem is available in Linux 4.3+.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This adds runtime state information for oci container's so that it can
be persisted and used by external tools.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>