-
Notifications
You must be signed in to change notification settings - Fork 652
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
An image may have empty layers array #313
An image may have empty layers array #313
Conversation
@@ -139,7 +139,7 @@ Unlike the [Manifest List](#manifest-list), which contains information about a s | |||
|
|||
- **`layers`** *array* | |||
|
|||
Each item in the array MUST be a [descriptor](descriptor.md). | |||
This property MAY be empty, an image can have an empty layers array. Each item in the array MUST be a [descriptor](descriptor.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.
I think this should be “This OPTIONAL property”. And we should stick to the one sentence per line rule.
To make this change clear, I think we also want the validation fix in #308, omitempty
in the Go property, and dropping layers
from required
in schema/image-manifest-schema.json
.
Wait, I didn't state that Layers is optional and the other stuff in #313 (comment) - I just opened this discussion in #308 because there are some discrepancies around the repo. I would wait for @vbatts @philips @stevvooe and others to chime in here before making any other fix to this PR |
@@ -139,7 +139,7 @@ Unlike the [Manifest List](#manifest-list), which contains information about a s | |||
|
|||
- **`layers`** *array* | |||
|
|||
Each item in the array MUST be a [descriptor](descriptor.md). | |||
This property MAY be empty, an image can have an empty layers array. Each item in the array MUST be a [descriptor](descriptor.md). | |||
The array MUST have the base image at index 0. | |||
Subsequent layers MUST then follow in the order in which they are to be layered on top of each other. |
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.
These two lines should be restructured to avoid requiring a zero-index layer. Something like:
The root filesystem MUST match an empty directory onto which the layers have been [applied](layer.md#applying) in the listed order.
With “match” instead of “be” to allow folks to apply via a union filesystem or whatever. As long as the finished product is right.
Signed-off-by: Lei Jitang <[email protected]>
On Wed, Sep 14, 2016 at 02:39:35AM -0700, Antonio Murdaca wrote:
Waiting for feedback is good. My motivation for OPTIONAL is that |
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 the purpose of a layerless manifest? I don't think makes any sense at all.
@@ -139,7 +139,7 @@ Unlike the [Manifest List](#manifest-list), which contains information about a s | |||
|
|||
- **`layers`** *array* | |||
|
|||
Each item in the array MUST be a [descriptor](descriptor.md). | |||
This property MAY be empty, an image can have an empty layers array. Each item in the array MUST be a [descriptor](descriptor.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.
Let's not mangle this line. The fact that these are descriptors is way more important than whether or not it can be empty.
Indeed mine was just a question (for which I just removed 3 lines of code and happy to put them back) |
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.
Didn't mean to approve anything here: I think we should close this.
I've already tweeted in anger. 😸
I'll be honest: I am confused here. What is the purpose of an image with no layers? The only thing I can imagine is a common distributed command that would run against a default rootfs (perhaps the host). Very weird and I am not sure if the use case is valid or viable. |
I did the same 😸 |
On Wed, Sep 14, 2016 at 01:15:20PM -0700, Stephen Day wrote:
You might be mounting in the meat from somewhere outside the bundle |
@wking How is that a valid use case for a distributable image? What are you distributing at that point? A command? |
On Wed, Sep 14, 2016 at 01:55:48PM -0700, Stephen Day wrote:
You're distributing the config, which has more than the command (but |
While the use case might seem particularly uncommon, I don't think it's necessarily invalid, nor have a strong reason to disallow it (I don't see it as putting any real burden on implementers for example). So I'm okay with this change in principle. |
@jonboulle What does it mean, though? |
@stevooe similar to the previous suggestions - basically a distributable runtime/exec config, where the root filesystem might be supplied from the host, or a volume mount, or ... |
@jonboulle Ok, but I think this needs to be thought through further. Wouldn't it be better for the spec to reserve the layerless image and then we can think it through? |
On Fri, Sep 16, 2016 at 01:15:15PM -0700, Stephen Day wrote:
With the wording of #318 making it explicit, it means that the |
On Fri, Sep 16, 2016 at 01:29:27PM -0700, Stephen Day wrote:
No need to reserve it, just 1:
for now and drop that line once you're comfortable doing so. |
Most folks will distribute images containing layers, but the specified behavior applies cleanly to the layer-less case too. The unpacked rootfs will just be an empty directory with unspecified attributes. Folks might want to use that sort of thing for namespace pinning [1], distributing configs [2], setting up containers that mount the meat from the host [2], etc. [1]: opencontainers/runtime-spec#395 (comment) [2]: opencontainers#313 (comment) Signed-off-by: W. Trevor King <[email protected]>
Let's resolve this via #318. |
Most folks will distribute images containing layers, but the specified behavior applies cleanly to the layer-less case too. The unpacked rootfs will just be an empty directory with unspecified attributes. Folks might want to use that sort of thing for namespace pinning [1], distributing configs [2], setting up containers that mount the meat from the host [2], etc. [1]: opencontainers/runtime-spec#395 (comment) [2]: opencontainers#313 (comment) Signed-off-by: W. Trevor King <[email protected]>
Most folks will distribute images containing layers, but the specified behavior applies cleanly to the layer-less case too. The unpacked rootfs will just be an empty directory with unspecified attributes. Folks might want to use that sort of thing for namespace pinning [1], distributing configs [2], setting up containers that mount the meat from the host [2], etc. [1]: opencontainers/runtime-spec#395 (comment) [2]: opencontainers#313 (comment) Signed-off-by: W. Trevor King <[email protected]>
Most folks will distribute images containing layers, but the specified behavior applies cleanly to the layer-less case too. The unpacked rootfs will just be an empty directory with unspecified attributes. Folks might want to use that sort of thing for namespace pinning [1], distributing configs [2], setting up containers that mount the meat from the host [2], etc. [1]: opencontainers/runtime-spec#395 (comment) [2]: opencontainers#313 (comment) Signed-off-by: W. Trevor King <[email protected]>
Most folks will distribute images containing layers, but the specified behavior applies cleanly to the layer-less case too. The unpacked rootfs will just be an empty directory with unspecified attributes. Folks might want to use that sort of thing for namespace pinning [1], distributing configs [2], setting up containers that mount the meat from the host [2], etc. [1]: opencontainers/runtime-spec#395 (comment) [2]: opencontainers#313 (comment) Signed-off-by: W. Trevor King <[email protected]>
Most folks will distribute images containing layers, but the specified behavior applies cleanly to the layer-less case too. The unpacked rootfs will just be an empty directory with unspecified attributes. Folks might want to use that sort of thing for namespace pinning [1], distributing configs [2], setting up containers that mount the meat from the host [2], etc. [1]: opencontainers/runtime-spec#395 (comment) [2]: opencontainers#313 (comment) Signed-off-by: W. Trevor King <[email protected]>
Most folks will distribute images containing layers, but the specified behavior applies cleanly to the layer-less case too. The unpacked rootfs will just be an empty directory with unspecified attributes. Folks might want to use that sort of thing for namespace pinning [1], distributing configs [2], setting up containers that mount the meat from the host [2], etc. [1]: opencontainers/runtime-spec#395 (comment) [2]: opencontainers#313 (comment) Signed-off-by: W. Trevor King <[email protected]>
Most folks will distribute images containing layers, but the specified behavior applies cleanly to the layer-less case too. The unpacked rootfs will just be an empty directory with unspecified attributes. Folks might want to use that sort of thing for namespace pinning [1], distributing configs [2], setting up containers that mount the meat from the host [2], etc. [1]: opencontainers/runtime-spec#395 (comment) [2]: opencontainers#313 (comment) Signed-off-by: W. Trevor King <[email protected]>
Most folks will distribute images containing layers, but the specified behavior applies cleanly to the layer-less case too. The unpacked rootfs will just be an empty directory with unspecified attributes. Folks might want to use that sort of thing for namespace pinning [1], distributing configs [2], setting up containers that mount the meat from the host [2], etc. [1]: opencontainers/runtime-spec#395 (comment) [2]: opencontainers#313 (comment) Signed-off-by: W. Trevor King <[email protected]>
On Fri, Sep 16, 2016 at 01:59:25PM -0700, Jonathan Boulle wrote:
I've closed #318 because there seemed to be a consensus around part of |
Signed-off-by: Lei Jitang [email protected]
from https://github.com/opencontainers/image-spec/pull/305/files/17c1f00097a716ca369d089159dd9569e7a0e0d0#r78707107
make this clear in manifest.md