-
Notifications
You must be signed in to change notification settings - Fork 553
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
Mount correction #854
Mount correction #854
Conversation
Fixed white-space errors. |
config.md
Outdated
@@ -59,6 +59,7 @@ For Solaris, the mount entry corresponds to the 'fs' resource in the [zonecfg(1M | |||
|
|||
* **`destination`** (string, REQUIRED) Destination of mount point: path inside container. | |||
This value MUST be an absolute path. | |||
* Posix: the path and child directories MUST exist, a runtime MUST NOT create directories automatically to a mount point. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something very like this change was rejected in #591.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but currently it is incorrect, as it states this in config.go for Windows where that statement is incorrect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but currently it is incorrect, as it states this in config.go for Windows where that statement is incorrect.
The Markdown is normative, and the Go comments are not. I'm in favor of removing the incorrect Go comment (like you do in this PR), and in general making the Go comments as simple as possible to avoid this sort of problem. But I don't want to carry incorrect Go comments back into the normative Markdown (like you do in this hunk).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear then, you recommend removing the addition both here, and keep the removal in config.go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear then, you recommend removing the addition both here, and keep the removal in config.go.
Yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done and update pushed.
config.md
Outdated
@@ -69,7 +70,7 @@ For Solaris, the mount entry corresponds to the 'fs' resource in the [zonecfg(1M | |||
* Windows: a local directory on the filesystem of the container host. UNC paths and mapped drives are not supported. | |||
* Solaris: corresponds to "special" of the fs resource in [zonecfg(1M)][zonecfg.1m]. | |||
* **`options`** (array of strings, OPTIONAL) Mount options of the filesystem to be used. | |||
* Linux: supported options are listed in the [mount(8)][mount.8] man page. Note both [filesystem-independent][mount.8-filesystem-independent] and [filesystem-specific][mount.8-filesystem-specific] options are listed. | |||
* Linux: supported options are listed in the [mount(8)][mount.8] man page. Note both [filesystem-independent][mount.8-filesystem-independent] and [filesystem-specific][mount.8-filesystem-specific] options are listed. In the case of bind mounts, this would be the file on the host. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
options
does not include a file from the host for bind mounts. More on bind mounts in #771, which I hope to revive after opencontainers/runc#1442 lands and I can PR runC support for (no)lazytime
, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change here (moving from config.go to config.md is purely for consistency. I haven't changed anything semantically as the statement already exists.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't changed anything semantically as the statement already exists.
Moving text from the non-normative Go comments to the normative Markdown spec is a semantic change. I'd rather this PR just adjusted the Go comments to not conflict with the Markdown spec while leaving the Markdown spec alone (unless you intend to make a semantic change, in which case you have to adjust the Markdown spec).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather this PR just adjusted the Go comments to not conflict with the Markdown spec
I'm still confused. What exactly do you believe is incorrect here. Are you saying the statement In the case of bind mounts, this would be the file on the host.
is invalid? It's inconsistent to have it in the go code, so where should it go? Or should it be entirely removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you saying the statement In the case of bind mounts, this would be the file on the host. is invalid?
Yes.
It's inconsistent to have it in the go code, so where should it go?
I think the Go comments should be as short and sweet as possible to avoid these inconsistencies. The more of the spec that gets echoed in the Go comments, the less DRY we are and the more likely we have these inconsistencies.
Or should it be entirely removed?
Yes, I'd like this PR to remove it from the Go comment but not inject it into the Markdown.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. Update pushed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you saying the statement In the case of bind mounts, this would be the file on the host. is invalid?
Yes.
Actually, the current Go comment belongs to source
, not options
(although you're adding it under options
here). So the current Go comment is correct in master, and might conceivably be useful in Markdown (under source
). Although with the current spec having nothing to say about bind mounts and with #771 rejected at the moment, I think copying this one line over to Markdown without filling in the rest of a bind-mount spec isn't particularly useful.
I'm still in favor of removing it from the Go comment to avoid having this line go stale or conflict as the Markdown evolves.
Type string `json:"type,omitempty"` | ||
// Source specifies the source path of the mount. In the case of bind mounts on | ||
// Linux based systems this would be the file on the host. | ||
Type string `json:"type,omitempty" platform:"linux,solaris"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently type
is still defined for Windows, we just require it to be unset. I'd rather move it to a POSIX-specific subsection (like we already do for UID/GID) so the field would be undefined in the Windows-track spec. More on this distinction here and in #680. But as long as the Markdown docs define the property for Windows (even if they forbid it), I don't think we want to add this platform
tag here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand this comment. Is this change not entirely consistent with the User
struct, and the UID
, GID
, AdditionalGids
and Username
fields of it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand this comment.
I'm saying I'd like something closer to:
## Mounts
…current section contents without `type`…
### Linux and Solaris Mounts
For Linux- and Solaris-based systems the mount structure has the following additional properties:
* **`type`** (string, OPTIONAL) …
Then a Windows config setting mounts[].type
would be in the same boat as a Windows config setting process.users.uid
(although the discussion in #680 shows that what that boat means could still use clarification).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see. It confused me because the comment was against config.go
when really you're referring to config.md
....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It confused me because the comment was against
config.go
when really you're referring toconfig.md
....
I'm saying that your current platform:"linux,solaris"
addition here is not as clearly backed by the Markdown spec as I'd like. I agree that it's where we want the Go type to end up, so I'd like to see your Go change, but I'd also like to see the Markdown adjusted to more clearly support the Go change. In the absence of the Markdown change, I'd rather wait on the Go change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, that's done. But I've been consistent with the existing User
markdown. Specifically, it does not have a training -
after Linux and Solaris as per your example. No use of the word additional
. And uses the term fields
rather than properties
.
Update pushed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No use of the word
additional
.
In the process.user
case, the platform-specific sections cover the only properties for that object. In this case, the Linux/Solaris section will be adding a new property to the existing platform-independent properties. The best precedent we have for that is probably here, which doesn't use “additional” either. I'd be happier with “additional” or some other language that makes it clear that both the platform-independent properties and the POSIX-specific type
are valid entries, but I'm ok punting that clarification to follow-up work.
I'd rather have the other bits changed too (e.g. we do use the hypenated “Linux-based” here), but I'm fine punting those to follow-up work as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed on a follow-up consistency PR covering the markdown generally.
c18de44
to
4b40119
Compare
* **`type`** (string, OPTIONAL) The type of the filesystem to be mounted. | ||
* Linux: filesystem types supported by the kernel as listed in */proc/filesystems* (e.g., "minix", "ext2", "ext3", "jfs", "xfs", "reiserfs", "msdos", "proc", "nfs", "iso9660"). | ||
* Solaris: corresponds to "type" of the fs resource in [zonecfg(1M)][zonecfg.1m]. | ||
|
||
### Example (Linux) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This (and the Solaris example) may want another #
to nest them under Linux and Solaris Mounts
. But since the examples are not just about type
, I'm also ok leaving them with ###
headers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I thought about adding another #
, but decided against it for that reason.
|
||
* **`type`** (string, OPTIONAL) The type of the filesystem to be mounted. | ||
* Linux: filesystem types supported by the kernel as listed in */proc/filesystems* (e.g., "minix", "ext2", "ext3", "jfs", "xfs", "reiserfs", "msdos", "proc", "nfs", "iso9660"). | ||
* Solaris: corresponds to "type" of the fs resource in [zonecfg(1M)][zonecfg.1m]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can reduce future conflicts with #846 by adjusting these to use four-space indents when we touch the lines. That doesn't have to happen in this PR, but I think it's useful for reducing the rebase load on @Mashimiao if this PR lands first.
Should this be tagged for 1.0? |
@jhowardmsft can you rebase this? |
Signed-off-by: John Howard <[email protected]>
@crosbymichael done |
Signed-off-by: John Howard [email protected]
a) Tagged the
type
of mount with the correct platform tag (not applicable onWindows
.b) Generally, there are not platform specific comments inside the
.go
files - that why we have the.md
files. Hence moved theLinux
comments for mount fromconfig.go
toconfig.md
.c) The comment about
the path and child directories MUST exist, a runtime MUST NOT create directories automatically to a mount point.
is incorrect in the way mapped directories (which is what the runtime uses through HCS to provide "pseudo"-mounts on Windows) work. Hence made that aPosix
comment.