Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

config-linux: specify the default devices/filesystems available #164

Merged
merged 1 commit into from
Sep 9, 2015

Conversation

philips
Copy link
Contributor

@philips philips commented Sep 9, 2015

Fixes #95

Signed-off-by: Brandon Philips [email protected]

@philips philips added this to the draft milestone Sep 9, 2015
@wking
Copy link
Contributor

wking commented Sep 9, 2015

I'm still in favor of just mounting devtmpfs for the devices 1.
That's currently broken in runC (opencontainers/runc#243), but the
spec shouldn't block based on runtime implementations. The only
devtmpfs pushback I've heard is that you don't want the mounted
devices to depend on optional kernel features [2,3], but it seems like
the two sticky cases would be things like:

a. The kernel doesn't support tmpfs, /dev/random, or some other
feature this PR would require.
b. The kernel suppoers devices (like /dev/comedi0) that this PR
doesn't require.

For (a), I'd rather allow those systems to use OCI bundles, even
though they have a very limited kernel. Does that sound ok to you?

For (b), I'd rather get those devices auto-mounted via devtmpfs. You
can always use cgroups to blacklist/whitelist devices you don't want
the container accessing, so I don't see a problem with exposing them
via devtmpfs. Does that sound ok to you?

@crosbymichael
Copy link
Member

LGTM

2 similar comments
@vbatts
Copy link
Member

vbatts commented Sep 9, 2015

LGTM

@mrunalp
Copy link
Contributor

mrunalp commented Sep 9, 2015

LGTM

mrunalp pushed a commit that referenced this pull request Sep 9, 2015
config-linux: specify the default devices/filesystems available
@mrunalp mrunalp merged commit fbac038 into opencontainers:master Sep 9, 2015
@wking
Copy link
Contributor

wking commented Sep 9, 2015

On Wed, Sep 09, 2015 at 10:16:49AM -0700, Mrunal Patel wrote:

Merged #164.

Just to document the devtmpfs resolution, in today's call we decided
that:

  • This is a required lower bar. So trying to run an OCI runtime on
    kernels like (a) in my previous post without /dev/random 1 will
    result in errors.
  • Runtimes will only create devices if the listed entry is missing.
    That way we don't clobber entries in the host's filesystem if the
    user launches a container without a mount namespace.
  • Runtimes will create the listed devices before iterating through
    config-specified mounts. So you can bind-mount the required entries
    to other locations via your config-specified mounts (although I'm
    not sure why you would want to do that ;). This last point didn't
    get a lot of airtime in the call, so it may not be settled.

wking added a commit to wking/ocitools that referenced this pull request Dec 5, 2015
Since opencontainers/runtime-spec#164 (part of the v0.1.1 release [1]), Linux
runtimes are required to supply these devices and mounts.  Specifying
them explicitly in the config should have no effect, and just makes
the config longer than it needs to be.

[1]: https://github.com/opencontainers/specs/blob/v0.1.1/config-linux.md#default-devices-and-file-systems

Signed-off-by: W. Trevor King <[email protected]>
wking added a commit to wking/ocitools that referenced this pull request Dec 5, 2015
Linux runtimes are not required to supply this [1,2].  We could supply
it via ocitool, but I don't think its wise to try and define two
standards (one in opencontainers/specs for what a runtime must supply,
and another here with additional stuff), because I don't see a clear
definition of something generally useful enough to go here but not in
the spec.  For example, hosts without CONFIG_POSIX_MQUEUE could be
spec-compliant but unable to perform the mqueue mount I'm removing
here.

[1]: https://github.com/opencontainers/specs/blob/v0.1.1/config-linux.md#default-devices-and-file-systems
[2]: opencontainers/runtime-spec#164

Signed-off-by: W. Trevor King <[email protected]>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Dec 28, 2015
Reverting 7232e4b (specs: introduce the concept of a runtime.json,
2015-07-30, opencontainers#88) after discussion on the mailing list [1].  The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec.  Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.

There have been a number of additional changes since opencontainers#88, so this
isn't a pure Git reversion.  Besides copy-pasting and the associated
link-target updates, I've:

* Restored path -> destination, now that the mount type contains both
  source and target paths again.  I'd prefer 'target' to 'destination'
  to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
  (possibly due to Windows using 'target' for the source?).

* Restored the Windows mount example to it's pre-7232e4b1 content.

* Removed required mounts from the config example (requirements landed
  in 3848a23, config-linux: specify the default devices/filesystems
  available, 2015-09-09, opencontainers#164), because specifying those mounts in the
  config is now redundant.

* Used headers (vs. bold paragraphs) to set off mount examples so we
  get link anchors in the rendered Markdown.

* Replaced references to runtime.json with references to config.json.

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
     Subject: Single, unified config file (i.e. rolling back specs#88)
     Date: Wed, 4 Nov 2015 09:53:20 -0800
     Message-ID: <[email protected]>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Dec 28, 2015
Reverting 7232e4b (specs: introduce the concept of a runtime.json,
2015-07-30, opencontainers#88) after discussion on the mailing list [1].  The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec.  Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.

There have been a number of additional changes since opencontainers#88, so this
isn't a pure Git reversion.  Besides copy-pasting and the associated
link-target updates, I've:

* Restored path -> destination, now that the mount type contains both
  source and target paths again.  I'd prefer 'target' to 'destination'
  to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
  (possibly due to Windows using 'target' for the source?).

* Restored the Windows mount example to its pre-7232e4b1 content.

* Removed required mounts from the config example (requirements landed
  in 3848a23, config-linux: specify the default devices/filesystems
  available, 2015-09-09, opencontainers#164), because specifying those mounts in the
  config is now redundant.

* Used headers (vs. bold paragraphs) to set off mount examples so we
  get link anchors in the rendered Markdown.

* Replaced references to runtime.json with references to config.json.

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
     Subject: Single, unified config file (i.e. rolling back specs#88)
     Date: Wed, 4 Nov 2015 09:53:20 -0800
     Message-ID: <[email protected]>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Dec 28, 2015
Reverting 7232e4b (specs: introduce the concept of a runtime.json,
2015-07-30, opencontainers#88) after discussion on the mailing list [1].  The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec.  Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.

There have been a number of additional changes since opencontainers#88, so this
isn't a pure Git reversion.  Besides copy-pasting and the associated
link-target updates, I've:

* Restored path -> destination, now that the mount type contains both
  source and target paths again.  I'd prefer 'target' to 'destination'
  to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
  (possibly due to Windows using 'target' for the source?).

* Restored the Windows mount example to its pre-7232e4b1 content.

* Removed required mounts from the config example (requirements landed
  in 3848a23, config-linux: specify the default devices/filesystems
  available, 2015-09-09, opencontainers#164), because specifying those mounts in the
  config is now redundant.

* Used headers (vs. bold paragraphs) to set off mount examples so we
  get link anchors in the rendered Markdown.

* Replaced references to runtime.json with references to config.json.

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
     Subject: Single, unified config file (i.e. rolling back specs#88)
     Date: Wed, 4 Nov 2015 09:53:20 -0800
     Message-ID: <[email protected]>

Signed-off-by: W. Trevor King <[email protected]>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Dec 28, 2015
Reverting 7232e4b (specs: introduce the concept of a runtime.json,
2015-07-30, opencontainers#88) after discussion on the mailing list [1].  The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec.  Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.

There have been a number of additional changes since opencontainers#88, so this
isn't a pure Git reversion.  Besides copy-pasting and the associated
link-target updates, I've:

* Restored path -> destination, now that the mount type contains both
  source and target paths again.  I'd prefer 'target' to 'destination'
  to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
  (possibly due to Windows using 'target' for the source?).

* Restored the Windows mount example to its pre-7232e4b1 content.

* Removed required mounts from the config example (requirements landed
  in 3848a23, config-linux: specify the default devices/filesystems
  available, 2015-09-09, opencontainers#164), because specifying those mounts in the
  config is now redundant.

* Used headers (vs. bold paragraphs) to set off mount examples so we
  get link anchors in the rendered Markdown.

* Replaced references to runtime.json with references to config.json.

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
     Subject: Single, unified config file (i.e. rolling back specs#88)
     Date: Wed, 4 Nov 2015 09:53:20 -0800
     Message-ID: <[email protected]>

Signed-off-by: W. Trevor King <[email protected]>
@wking wking mentioned this pull request Jan 7, 2016
@wking wking mentioned this pull request Jan 18, 2016
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Jan 20, 2016
Reverting 7232e4b (specs: introduce the concept of a runtime.json,
2015-07-30, opencontainers#88) after discussion on the mailing list [1].  The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec.  Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.

There have been a number of additional changes since opencontainers#88, so this
isn't a pure Git reversion.  Besides copy-pasting and the associated
link-target updates, I've:

* Restored path -> destination, now that the mount type contains both
  source and target paths again.  I'd prefer 'target' to 'destination'
  to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
  (possibly due to Windows using 'target' for the source?).

* Restored the Windows mount example to its pre-7232e4b1 content.

* Removed required mounts from the config example (requirements landed
  in 3848a23, config-linux: specify the default devices/filesystems
  available, 2015-09-09, opencontainers#164), because specifying those mounts in the
  config is now redundant.

* Used headers (vs. bold paragraphs) to set off mount examples so we
  get link anchors in the rendered Markdown.

* Replaced references to runtime.json with references to config.json.

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
     Subject: Single, unified config file (i.e. rolling back specs#88)
     Date: Wed, 4 Nov 2015 09:53:20 -0800
     Message-ID: <[email protected]>

Signed-off-by: W. Trevor King <[email protected]>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Jan 25, 2016
Reverting 7232e4b (specs: introduce the concept of a runtime.json,
2015-07-30, opencontainers#88) after discussion on the mailing list [1].  The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec.  Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.

There have been a number of additional changes since opencontainers#88, so this
isn't a pure Git reversion.  Besides copy-pasting and the associated
link-target updates, I've:

* Restored path -> destination, now that the mount type contains both
  source and target paths again.  I'd prefer 'target' to 'destination'
  to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
  (possibly due to Windows using 'target' for the source?).

* Restored the Windows mount example to its pre-7232e4b1 content.

* Removed required mounts from the config example (requirements landed
  in 3848a23, config-linux: specify the default devices/filesystems
  available, 2015-09-09, opencontainers#164), because specifying those mounts in the
  config is now redundant.

* Used headers (vs. bold paragraphs) to set off mount examples so we
  get link anchors in the rendered Markdown.

* Replaced references to runtime.json with references to config.json.

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
     Subject: Single, unified config file (i.e. rolling back specs#88)
     Date: Wed, 4 Nov 2015 09:53:20 -0800
     Message-ID: <[email protected]>

Signed-off-by: W. Trevor King <[email protected]>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Jan 25, 2016
Reverting 7232e4b (specs: introduce the concept of a runtime.json,
2015-07-30, opencontainers#88) after discussion on the mailing list [1].  The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec.  Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.

There have been a number of additional changes since opencontainers#88, so this
isn't a pure Git reversion.  Besides copy-pasting and the associated
link-target updates, I've:

* Restored path -> destination, now that the mount type contains both
  source and target paths again.  I'd prefer 'target' to 'destination'
  to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
  (possibly due to Windows using 'target' for the source?).

* Restored the Windows mount example to its pre-7232e4b1 content.

* Removed required mounts from the config example (requirements landed
  in 3848a23, config-linux: specify the default devices/filesystems
  available, 2015-09-09, opencontainers#164), because specifying those mounts in the
  config is now redundant.

* Used headers (vs. bold paragraphs) to set off mount examples so we
  get link anchors in the rendered Markdown.

* Replaced references to runtime.json with references to config.json.

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
     Subject: Single, unified config file (i.e. rolling back specs#88)
     Date: Wed, 4 Nov 2015 09:53:20 -0800
     Message-ID: <[email protected]>

Signed-off-by: W. Trevor King <[email protected]>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Jan 25, 2016
Reverting 7232e4b (specs: introduce the concept of a runtime.json,
2015-07-30, opencontainers#88) after discussion on the mailing list [1].  The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec.  Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.

There have been a number of additional changes since opencontainers#88, so this
isn't a pure Git reversion.  Besides copy-pasting and the associated
link-target updates, I've:

* Restored path -> destination, now that the mount type contains both
  source and target paths again.  I'd prefer 'target' to 'destination'
  to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
  (possibly due to Windows using 'target' for the source?).

* Restored the Windows mount example to its pre-7232e4b1 content.

* Removed required mounts from the config example (requirements landed
  in 3848a23, config-linux: specify the default devices/filesystems
  available, 2015-09-09, opencontainers#164), because specifying those mounts in the
  config is now redundant.

* Used headers (vs. bold paragraphs) to set off mount examples so we
  get link anchors in the rendered Markdown.

* Replaced references to runtime.json with references to config.json.

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
     Subject: Single, unified config file (i.e. rolling back specs#88)
     Date: Wed, 4 Nov 2015 09:53:20 -0800
     Message-ID: <[email protected]>

Signed-off-by: W. Trevor King <[email protected]>
wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Jan 27, 2016
Reverting 7232e4b (specs: introduce the concept of a runtime.json,
2015-07-30, opencontainers#88) after discussion on the mailing list [1].  The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec.  Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.

There have been a number of additional changes since opencontainers#88, so this
isn't a pure Git reversion.  Besides copy-pasting and the associated
link-target updates, I've:

* Restored path -> destination, now that the mount type contains both
  source and target paths again.  I'd prefer 'target' to 'destination'
  to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
  (possibly due to Windows using 'target' for the source?).

* Restored the Windows mount example to its pre-7232e4b1 content.

* Removed required mounts from the config example (requirements landed
  in 3848a23, config-linux: specify the default devices/filesystems
  available, 2015-09-09, opencontainers#164), because specifying those mounts in the
  config is now redundant.

* Used headers (vs. bold paragraphs) to set off mount examples so we
  get link anchors in the rendered Markdown.

* Replaced references to runtime.json with references to config.json.

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
     Subject: Single, unified config file (i.e. rolling back specs#88)
     Date: Wed, 4 Nov 2015 09:53:20 -0800
     Message-ID: <[email protected]>

Signed-off-by: W. Trevor King <[email protected]>
wking added a commit to wking/ocitools-v2 that referenced this pull request Mar 8, 2016
Since opencontainers/runtime-spec#164 (part of the v0.1.1 release [1]), Linux
runtimes are required to supply these devices and mounts.  Specifying
them explicitly in the config should have no effect, and just makes
the config longer than it needs to be.

[1]: https://github.com/opencontainers/specs/blob/v0.1.1/config-linux.md#default-devices-and-file-systems

Signed-off-by: W. Trevor King <[email protected]>
Mashimiao pushed a commit to Mashimiao/specs that referenced this pull request Aug 19, 2016
Reverting 7232e4b (specs: introduce the concept of a runtime.json,
2015-07-30, opencontainers#88) after discussion on the mailing list [1].  The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec.  Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.

There have been a number of additional changes since opencontainers#88, so this
isn't a pure Git reversion.  Besides copy-pasting and the associated
link-target updates, I've:

* Restored path -> destination, now that the mount type contains both
  source and target paths again.  I'd prefer 'target' to 'destination'
  to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
  (possibly due to Windows using 'target' for the source?).

* Restored the Windows mount example to its pre-7232e4b1 content.

* Removed required mounts from the config example (requirements landed
  in 3848a23, config-linux: specify the default devices/filesystems
  available, 2015-09-09, opencontainers#164), because specifying those mounts in the
  config is now redundant.

* Used headers (vs. bold paragraphs) to set off mount examples so we
  get link anchors in the rendered Markdown.

* Replaced references to runtime.json with references to config.json.

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
     Subject: Single, unified config file (i.e. rolling back specs#88)
     Date: Wed, 4 Nov 2015 09:53:20 -0800
     Message-ID: <[email protected]>

Signed-off-by: W. Trevor King <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants