-
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
Remove platform field #850
Conversation
config.md
Outdated
Values for **`arch`** SHOULD use, and runtimes SHOULD understand, **`arch`** entries listed in the Go Language document for [`GOARCH`][go-environment]. | ||
If an architecture is not included in the `GOARCH` documentation, it SHOULD be submitted to this specification for standardization. | ||
**`platform`** (string, REQUIRED) specifies the configuration's target platform. | ||
The value MUST be a slug from [the platform list](spec.md#platforms). |
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.
Not sure I like the word slug
... Item? Entry?
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.
Updated, thanks.
config.md
Outdated
* **`windows`** (object, OPTIONAL) [Windows-specific configuration](config-windows.md). | ||
This MAY be set if **`platform.os`** is `windows` and MUST NOT be set otherwise. |
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, this MUST be set if the platform is windows. A container isn't going to run at all without it. Not sure whether this applies to other platforms though.
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 we can open a new PR to fix this? It's non-relevant to this PR.
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 we can open a new PR to fix this?
#828 is covering this change, so we can leave this as MAY for this PR.
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.
Now that #828 has landed, this PR will need a rebase.
3cc7816
to
dc88c9e
Compare
Since this appears to map IMO dropping our |
On Wed, May 24, 2017 at 08:33:29AM -0700, Tianon Gravi wrote:
… and perhaps even reference image-spec…
There's no need for this, because the values come from the
runtime-spec platform list [1].
[1]: https://github.com/opencontainers/runtime-spec/blob/2ec18c02474dd49ce20aa30236959a8a80763042/spec.md#platforms
|
This seems like a step backwards. The only change needed to make it compatible with the image spec is |
@opencontainers/runtime-spec-maintainers More comments on this? I see many different suggestions and not sure which way to go. |
On Thu, Jun 01, 2017 at 08:11:13PM -0700, Qiang Huang wrote:
More comments on this? I see many different suggestions and not sure
which way to go.
I'm not a maintainer, but I think we want to gut the current platform
(like you're doing in dc88c9e) unless someone wants support for the
“I'm not sure if my runtime will execute this container on my current
host or some other platform…” use case [1]. I haven't heard anyone
advocating for that.
We'll need some way to declare your compliance track [2], and for that
I'm fine with either of:
a. Your ‘platform’ property where the value “MUST be an item from the
platform list [2]”.
b. @crosbymichael's ‘--platform’ option [3], with the same
compliance-track values [2].
I don't see much difference between a or b myself, but @crosbymichael
sees his proposal as more robust [3].
You could swing something more complicated like @tianon's proposal
[4], but I feel like using the platform-specific sections to both
select the compliance track *and* hold some subset of the
platform-specific properties is too overloaded [5].
[1]: #830 (comment)
[2]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc5/spec.md#platforms
[3]: #830 (comment)
[4]: #830 (comment)
[5]: #830 (comment)
|
Actually, just to throw one out there.... Windows will imminently be able to run both Windows and Linux containers. So it might matter. |
On Thu, Jun 01, 2017 at 08:47:56PM -0700, John Howard wrote:
Windows will imminently be able to run both Windows and Linux
containers. So it might matter.
The arch will matter?
I think all the proposals include some way to specify the compliance
track [1], so you can still send an explicitly-Linux config into a
runtime on a Windows host. Will the Windows runtime need any more
information than “this is a windows config” or “this is a linux
config”?
[1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc5/spec.md#platforms
|
I'm still figuring that out. It will need bits of the Windows and Linux sections - for example the LayerFolders in Windows are going to be required for the runtime, but much of the Linux section will need to be populated as that's where the Linux settings are. For 1.0, I'd probably ignore my comment, it was just in passing. However, there will definitely be quite a few spec updates required for multi-platform on a single OS. |
On Thu, Jun 01, 2017 at 08:55:41PM -0700, John Howard wrote:
It will need bits of the Windows and Linux sections - for example
the LayerFolders in Windows are going to be required for the
runtime, but much of the Linux section will need to be populated as
that's where the Linux settings are.
*shudder* Some of these host-vs.-container issues have come up in
#405, although I don't think compliance testing plans for those VM
settings have been worked out yet.
For 1.0, I'd probably ignore my comment…
Ok, so we're back to “nobody is asking for anything more than the
compliance track at the moment”.
|
config.md
Outdated
|
||
* **`os`** (string, REQUIRED) specifies the operating system family of the container configuration's specified [`root`](#root) file system bundle. | ||
The runtime MUST generate an error if it does not support the specified **`os`**. | ||
Bundles SHOULD use, and runtimes SHOULD understand, **`os`** entries listed in the Go Language document for [`GOOS`][go-environment]. |
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'll want to drop the reference at the ebd of this file too, since you remove the only consumers.
We discussed this on the call today and feel that it would be better to fully remove it from the spec. The tool that interprets the spec knows how/what platform it is built for or what platform it should use in the case of windows or VMs. @hqhq can you update this PR to remove the platform field fully? Validation tools will be told what they are validating a specific spec against. |
@crosbymichael Updated. |
config.md
Outdated
@@ -855,8 +823,7 @@ Here is a full example `config.json` for reference. | |||
[selinux]:http://selinuxproject.org/page/Main_Page | |||
[no-new-privs]: https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt | |||
[procfs_2]: https://www.kernel.org/doc/Documentation/filesystems/proc.txt | |||
[semver-v2.0.0]: http://semver.org/spec/v2.0.0.html | |||
[go-environment]: https://golang.org/doc/install/source#environment | |||
[semver-v3.0.0]: http://semver.org/spec/v2.0.0.html |
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 don't think you want to bump semver-v2.0.0
→ semver-v3.0.0
(especially since 2.0.0 is still the most recent version ;).
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.
Indeed -- minus this change, the rest of this PR LGTM now. 👍
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.
Oops, no idea where that change comes from, updated.
Close: opencontainers#725 See discussion in opencontainers#830 and dev-weekly-meeting discussion in http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2017/opencontainers.2017-06-14-21.03.log.txt We don't use this field in runc, and mostly only image-spec cares about this, we can assume tools know what specific platform this spec is built for. Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Sorry for asking so late. I have a question. |
The runtime will have a compiled-in favorite. For example, a Linux build of Tools that can handle configs for multiple platforms (e.g. |
1 similar comment
Through 63b7c6c (Merge pull request opencontainers#850 from hqhq/simply_platform, 2017-06-16). Signed-off-by: W. Trevor King <wking@tremily.us>
Close: #725
See discussion in #830 and dev-weekly-meeting discussion
in http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2017/opencontainers.2017-06-14-21.03.log.txt
We don't use this field in runc, and mostly only
image-spec cares about this, we can assume tools know
what specific platform this spec is built for.
Signed-off-by: Qiang Huang h.huangqiang@huawei.com