-
Notifications
You must be signed in to change notification settings - Fork 541
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.md: document what type should be when bind-mount #878
Conversation
I re-read config.md and found we really didn't define what type should be if we want to do bind-mount. So, I decided to add it. Signed-off-by: Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
I think these semantics are implied already by referencing |
Indeed, |
On Wed, Jul 05, 2017 at 08:01:49AM -0700, Tianon Gravi wrote:
Indeed, `type` is explicitly optional and doesn't include language
about `bind` or `rbind`, so while I think this case is worth having
more language around, I'm pushing it to post-1.0.
But there's currently no spec wording about the (r)bind use case at
all, despite an example which uses it [1]. I'd rather re-open #771
and actually define those options now that opencontainers/runc#1460
has landed (removing the reason #771 was closed, which I think was
“this doesn't match the current runC implementation” although [2]
doesn't say). #771 will need some re-rolling to bring it up to speed
with the current master, but I'm leaving the branch alone until the PR
is re-opened.
[1]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0-rc6/config.md#L120
[2]: #771 (comment)
|
I'm a little bit late to the party... but I agree it would be useful for runtime developers to clarify the expected semantic here. For instance, it seems like |
On Thu, Apr 12, 2018 at 10:11:32PM +0000, Felix Abecassis wrote:
For instance, it seems like `runc` doesn't ignore the `bind` type, as it should here (?)
https://github.com/opencontainers/runc/blob/f753f300ae6a725becddbacf15955a0a03b895cb/libcontainer/specconv/spec_linux.go#L272-L276
I've filed opencontainers/runc#1753 for that, and @cyphar sounded
positive in early review [1]. However, the associated spec PR (#954)
was recently closed by @vbatts [2]. I'm not sure where that leaves us
on the “should” front. But however the spec maintainers want bind
mounts to work, I think they should get some docs about them landed so
the rest of us can do the right thing ;).
[1]: opencontainers/runc#1753 (comment)
[2]: #954 (comment)
|
|
On Thu, Apr 12, 2018 at 10:51:36PM +0000, Felix Abecassis wrote:
`bind` is clearly not a valid type.
I dunno about “clearly” ;). The current spec has nothing about “bind”
outside of an informative example [1]. *I* agree that the current
normative spec wording [2] makes it sound like values should be
entries in /proc/filesystems, but @vbatts explicitly disagrees [3].
And there's certainly no MUST or other RFC 2119 wording in the ‘type’
specification to restrict either the configured values or the runtime
interpretation of those values.
In general, if an unknown type is present, I think it MUST be
ignored (which is what fstab does, AFAIK).
That's fine with me, and the wording in this PR is a step in that
direction (although it's currently only SHOULDing the runtime to
ignore the value). I'm just saying that the current situation is
unclear, and that I wish the spec had more language that went into
detail on how bind configuration works. Which is basically what
@tianon said back in [4]. Now that we're 274 days post 1.0.0, perhaps
some maintainers can circle back around to this PR?
[1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.1/config.md#example-linux
[2]: https://github.com/opencontainers/runtime-spec/blob/v1.0.1/config.md#posix-platform-mounts
[3]: #954 (comment)
[4]: #878 (comment)
|
Bind is an odd one. There are places on Linux that it's treated like type,
but yes it's not an absolute type. It seems like a clarity or usability to
keep it as a type for OCI.
…On Thu, Apr 12, 2018, 19:59 W. Trevor King ***@***.***> wrote:
On Thu, Apr 12, 2018 at 10:51:36PM +0000, Felix Abecassis wrote:
> `bind` is clearly not a valid type.
I dunno about “clearly” ;). The current spec has nothing about “bind”
outside of an informative example [1]. *I* agree that the current
normative spec wording [2] makes it sound like values should be
entries in /proc/filesystems, but @vbatts explicitly disagrees [3].
And there's certainly no MUST or other RFC 2119 wording in the ‘type’
specification to restrict either the configured values or the runtime
interpretation of those values.
> In general, if an unknown type is present, I think it MUST be
> ignored (which is what fstab does, AFAIK).
That's fine with me, and the wording in this PR is a step in that
direction (although it's currently only SHOULDing the runtime to
ignore the value). I'm just saying that the current situation is
unclear, and that I wish the spec had more language that went into
detail on how bind configuration works. Which is basically what
@tianon said back in [4]. Now that we're 274 days post 1.0.0, perhaps
some maintainers can circle back around to this PR?
[1]:
https://github.com/opencontainers/runtime-spec/blob/v1.0.1/config.md#example-linux
[2]:
https://github.com/opencontainers/runtime-spec/blob/v1.0.1/config.md#posix-platform-mounts
[3]:
#954 (comment)
[4]:
#878 (comment)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#878 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEF6f7DwYRAh2mqpiaTOUUKUzQwugoGks5tn-pVgaJpZM4OKMKS>
.
|
So do you agree with @tianon that it could use more spec wording? If so, what sort of wording would you like to see? |
This is a fairly long-standing bug in |
A general |
Ah, I forgot about that patch. Yes that works and will fix the issue (and we should probably merge it), but it's just taking advantage of the already broken code -- fixing the broken-ness will be much more annoying to do. 😉 |
obsoleted by #981 |
I re-read config.md and found we really didn't define what
type should be if we want to do bind-mount.
So, I decided to add it.
Signed-off-by: Ma Shimiao mashimiao.fnst@cn.fujitsu.com