-
Notifications
You must be signed in to change notification settings - Fork 557
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
Windows: Remove Sandbox, additional tweaks #849
Conversation
config.md
Outdated
@@ -31,7 +31,7 @@ For example, if a configuration is compliant with version 1.1 of this specificat | |||
* **`path`** (string, OPTIONAL) Specifies the path to the root filesystem for the container. The path is either an absolute path or a relative path to the bundle. | |||
Users SHOULD consider using a conventional name, such as `rootfs`. | |||
|
|||
On Windows, for Windows Server Containers, this field is REQUIRED. For Hyper-V Containers, this field MUST be omitted. | |||
On Windows, for Windows Server Containers, this field is REQUIRED and MUST be specified as a Win32 file namespace volume path. For Hyper-V Containers, this field MUST be omitted. |
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.
What is “Win32 file namespace volume path”? Can we get a doc link (maybe this?)? Ideally this MUST would be backed up by a stable link to a spec defining that term with sufficient detail for runtime-tools validation to determine if a given root.path
value met the requirement or not.
And I'm also touching this line in #838. That change is orthogonal to your addition here, but whichever PR lands second will likely need a rebase.
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.
Yes, that is the link. Will add.
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.
Actually, found a better link at https://msdn.microsoft.com/en-us/library/windows/desktop/aa365248(v=vs.85).aspx. Updated.
config.md
Outdated
|
||
```json | ||
"root": { | ||
"path": "\\\\?\\Volume{ec84d99e-3f02-11e7-ac6c-00155d7682cf}", |
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.
You should remove the trailing comma here to get a legal JSON fragment.
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.
Good catch. Fixed.
config.md
Outdated
``` | ||
|
||
|
||
|
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.
Almost all of the rest of the spec has a single empty line before a new header, so I'd recommend reducing your number of empty lines here from three to one.
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.
Yup, fixed too.
34aa5e2
to
9bf68d9
Compare
config.md
Outdated
@@ -31,7 +31,7 @@ For example, if a configuration is compliant with version 1.1 of this specificat | |||
* **`path`** (string, OPTIONAL) Specifies the path to the root filesystem for the container. The path is either an absolute path or a relative path to the bundle. | |||
Users SHOULD consider using a conventional name, such as `rootfs`. | |||
|
|||
On Windows, for Windows Server Containers, this field is REQUIRED. For Hyper-V Containers, this field MUST be omitted. | |||
On Windows, for Windows Server Containers, this field is REQUIRED and MUST be specified as a volume GUID path. For more information, see [MSDN documentation][naming-a-volume]. For Hyper-V Containers, this field MUST be omitted. |
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.
Maybe “see MSDN documentation” → “see the MSDN documentation”? Or use:
… MUST be specified as a volume GUID path.
and drop the “For more information” sentence?
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.
Sure. Went with the latter. Updated.
config.md
Outdated
|
||
```json | ||
"root": { | ||
"path": "\\\\?\\Volume{ec84d99e-3f02-11e7-ac6c-00155d7682cf}" |
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 docs you link give the pattern as \\?\Volume{GUID}\
and say:
All volume and mounted folder functions that take a volume GUID path as an input parameter require the trailing backslash.
before talking about a CreateFile
caveat. I'm not sure if the Windows runtime will always use CreateFile
to back this property, or if CreateFile
distinguishes between backslash-terminated or not volume GUID paths, but I expect you either want to add a trailing backslash here or add some words up above about why you don't need 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.
The trailing backslash doesn't actually matter. The example I gave was pasted from a breakpoint on a live running container.
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.
That said, I'm seeing whether HCS itself can cope if a trailing backslash is supplied.
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 trailing backslash doesn't actually matter.
So say that in the docs? Perhaps:
… MUST be specified as a volume GUID path (a trailing backslash is OPTIONAL)…
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 doesn't. Will update 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.
Actually, it's better that we follow MSDN from the spec. I will update the runtime to ensure the trailing backslash is removed if present before passing onto HCS. Updated here accordingly.
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's a path to a directory/volume, right? Trailing slash on those is almost always optional, and IMO there's no additional value in being explicit about that 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.
Trailing slash on those is almost always optional, and IMO there's no additional value in being explicit about that here.
I'd agree with that if the docs for volume GUID paths didn't require a trailing backslash in most cases.
7e0a43f
to
13a3169
Compare
config.md
Outdated
|
||
```json | ||
"root": { | ||
"path": "\\\\?\\Volume{ec84d99e-3f02-11e7-ac6c-00155d7682cf}\" |
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.
You need to double the trailing backslash to avoid escaping the closing quote.
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 thought so too, but it looks ok in preview mode.... Also in preview mode I see four backslashes at the start and I think there are only supposed to be two. So I'm beginning to question the need for the backslash of the backslashes.
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 four/two is correct :)
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.
But there should be two at the end.
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.
Okey Doke, I'll take @jhowardmsft word on this one. Thanks for the follow up.
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've pushed an update.
Signed-off-by: John Howard <[email protected]>
All comments addressed. Ready for review. |
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.
LGTM
On Wed, May 24, 2017 at 10:08:22AM -0700, John Howard wrote:
All comments addressed. Ready for review.
I'm not familiar enough with the underlying technology to comment on
that, but 2283e63 looks internally consistent to me.
|
@vbatts @mrunalp @crosbymichael OK to get this one merged now for the 1.0 RC cut-off? |
Don't require users targetting Hyper-V to set an empty object ("root": {}). This also avoids confusion about whether you can set root.readonly without setting root.path (you can't). Move the relative, absolute, and rootfs bits into a POSIX paragraph, because they don't apply to Windows where the value MUST be a volume GUID path (since 2283e63, Windows: Remove Sandbox, additional tweaks, 2017-05-23, opencontainers#849). We don't need the "for Windows Server containers" condition on volume GUID paths, because with this commit that condition is already applied at the 'root' level and the Hyper-V case has already been handled there. Signed-off-by: W. Trevor King <[email protected]>
Don't require users targetting Hyper-V to set an empty object ("root": {}). This also avoids confusion about whether you can set root.readonly without setting root.path (you can't). Move the relative, absolute, and rootfs bits into a POSIX paragraph, because they don't apply to Windows where the value MUST be a volume GUID path (since 2283e63, Windows: Remove Sandbox, additional tweaks, 2017-05-23, opencontainers#849). We don't need the "for Windows Server containers" condition on volume GUID paths, because with this commit that condition is already applied at the 'root' level and the Hyper-V case has already been handled there. Signed-off-by: W. Trevor King <[email protected]>
Don't require users targetting Hyper-V to set an empty object ("root": {}). This also avoids confusion about whether you can set root.readonly without setting root.path (you can't). Move the relative, absolute, and rootfs bits into a POSIX paragraph, because they don't apply to Windows where the value MUST be a volume GUID path (since 2283e63, Windows: Remove Sandbox, additional tweaks, 2017-05-23, opencontainers#849). We don't need the "for Windows Server containers" condition on volume GUID paths, because with this commit that condition is already applied at the 'root' level and the Hyper-V case has already been handled there. Signed-off-by: W. Trevor King <[email protected]>
SHOULD means that [1]: ... there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. So consideration is already baked into the definition, and we can just say "SHOULD be" and warn folks whenever they use a value other than 'rootfs'. Also move this under the non-Windows conditions, because the advice they doesn't apply to Windows where the value MUST be a volume GUID path (since 2283e63, Windows: Remove Sandbox, additional tweaks, 2017-05-23, opencontainers#849). [1]: https://tools.ietf.org/html/rfc2119#section-3 Signed-off-by: W. Trevor King <[email protected]>
Don't require users targetting Hyper-V to set an empty object ("root": {}). This also avoids confusion about whether you can set root.readonly without setting root.path (you can't). Move the relative, absolute, and rootfs bits into a POSIX paragraph, because they don't apply to Windows where the value MUST be a volume GUID path (since 2283e63, Windows: Remove Sandbox, additional tweaks, 2017-05-23, opencontainers#849). We don't need the "for Windows Server containers" condition on volume GUID paths, because with this commit that condition is already applied at the 'root' level and the Hyper-V case has already been handled there. Signed-off-by: W. Trevor King <[email protected]>
Don't require users targetting Hyper-V to set an empty object ("root": {}). This also avoids confusion about whether you can set root.readonly without setting root.path (you can't). Move the relative, absolute, and rootfs bits into a POSIX paragraph, because they don't apply to Windows where the value MUST be a volume GUID path (since 2283e63, Windows: Remove Sandbox, additional tweaks, 2017-05-23, opencontainers#849). We don't need the "for Windows Server containers" condition on volume GUID paths, because with this commit that condition is already applied at the 'root' level and the Hyper-V case has already been handled there. Signed-off-by: W. Trevor King <[email protected]>
Don't require users targetting Hyper-V to set an empty object ("root": {}). This also avoids confusion about whether you can set root.readonly without setting root.path (you can't). Move the relative, absolute, and rootfs bits into a POSIX paragraph, because they don't apply to Windows where the value MUST be a volume GUID path (since 2283e63, Windows: Remove Sandbox, additional tweaks, 2017-05-23, opencontainers#849). We don't need the "for Windows Server containers" condition on volume GUID paths, because with this commit that condition is already applied at the 'root' level and the Hyper-V case has already been handled there. Signed-off-by: W. Trevor King <[email protected]>
Signed-off-by: John Howard [email protected]
This relates to conversations internally here finalising and verifying the changes necessary to support Windows in the v1.0 OCI spec. Specifically the first part of this comment: #828 (comment).
It turns out that between Technical Preview 5 (TP5) and RTM of Windows Server 2016, there was a platform change whereby the SandboxPath no longer needed to be passed, but was kept in for backwards compatibility as long as the layerfolderpath is populated between the runtime and HCS. I wasn't aware of this. Hence it's no longer needed in the spec. Apologies for the noise introducing it.
There are three other clarifications in this PR:
a) Clarify the root.Path for Windows Server containers and give an explicit example.
b) Fix the double-escaping in the utilityvmpath in
config-windows.md
.c) Removed old unused hyperlinks