Skip to content
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

Closed

Conversation

coolljt0725
Copy link
Member

@@ -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).
Copy link
Contributor

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.

@runcom
Copy link
Member

runcom commented Sep 14, 2016

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.
Copy link
Contributor

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.

@wking
Copy link
Contributor

wking commented Sep 14, 2016

On Wed, Sep 14, 2016 at 02:39:35AM -0700, Antonio Murdaca wrote:

Wait, I didn't state that Layers is optional and the other stuff in
#313 (comment)

I would wait for @vbatts @philips @stevvooe and others to chime in
here before making any other fix to this PR

Waiting for feedback is good. My motivation for OPTIONAL is that
there's no need to require folks to set an empty array when they could
express the same thing more compactly by leaving the property out of
their JSON.

Copy link
Contributor

@stevvooe stevvooe left a 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).
Copy link
Contributor

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.

@runcom
Copy link
Member

runcom commented Sep 14, 2016

What is the purpose of a layerless manifest? I don't think makes any sense at all.

Indeed mine was just a question (for which I just removed 3 lines of code and happy to put them back)

Copy link
Contributor

@stevvooe stevvooe left a 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.

@runcom
Copy link
Member

runcom commented Sep 14, 2016

Damn new UI - @stevvooe this has been started from #308 - I can re-put the layers check there if this is a non-sense

@stevvooe
Copy link
Contributor

Damn new UI -

I've already tweeted in anger. 😸

@stevvooe this has been started from #308 - I can re-put the layers check there if this is a non-sense

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.

@runcom
Copy link
Member

runcom commented Sep 14, 2016

Damn new UI -
I've already tweeted in anger.

I did the same 😸

@wking
Copy link
Contributor

wking commented Sep 14, 2016

On Wed, Sep 14, 2016 at 01:15:20PM -0700, Stephen Day wrote:

I'll be honest: I am confused here. What is the purpose of an image
with no layers?

You might be mounting in the meat from somewhere outside the bundle
directory. Or you might be using the initially-empty-rootfs container
to hold open a mount namespace for subcontainers 1.

@stevvooe
Copy link
Contributor

@wking How is that a valid use case for a distributable image? What are you distributing at that point? A command?

@wking
Copy link
Contributor

wking commented Sep 14, 2016

On Wed, Sep 14, 2016 at 01:55:48PM -0700, Stephen Day wrote:

@wking How is that a valid use case for a distributable image? What
are you distributing at that point? A command?

You're distributing the config, which has more than the command (but
not all that much more ;).

@jonboulle jonboulle changed the title An image may have emtpy layers array An image may have empty layers array Sep 16, 2016
@jonboulle
Copy link
Contributor

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.

@stevvooe
Copy link
Contributor

@jonboulle What does it mean, though?

@jonboulle
Copy link
Contributor

@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 ...

@stevvooe
Copy link
Contributor

@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?

@wking
Copy link
Contributor

wking commented Sep 16, 2016

On Fri, Sep 16, 2016 at 01:15:15PM -0700, Stephen Day wrote:

@jonboulle What does it mean, though?

With the wording of #318 making it explicit, it means that the
unpacked rootfs will be an empty directory with unspecified
attributes.

@stevvooe
Copy link
Contributor

With the wording of #318 making it explicit, it means that the
unpacked rootfs will be an empty directory with unspecified
attributes.

Ok, I agree. Could we merge the intent of this PR with #318 and close this one?

@wking
Copy link
Contributor

wking commented Sep 16, 2016

On Fri, Sep 16, 2016 at 01:29:27PM -0700, Stephen Day wrote:

@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?

No need to reserve it, just 1:

layers MUST contain at least one entry.

for now and drop that line once you're comfortable doing so.

wking added a commit to wking/image-spec that referenced this pull request Sep 16, 2016
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]>
@jonboulle
Copy link
Contributor

Let's resolve this via #318.

@jonboulle jonboulle closed this Sep 16, 2016
wking added a commit to wking/image-spec that referenced this pull request Sep 16, 2016
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]>
wking added a commit to wking/image-spec that referenced this pull request Sep 16, 2016
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]>
wking added a commit to wking/image-spec that referenced this pull request Oct 1, 2016
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]>
wking added a commit to wking/image-spec that referenced this pull request Oct 1, 2016
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]>
wking added a commit to wking/image-spec that referenced this pull request Oct 6, 2016
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]>
wking added a commit to wking/image-spec that referenced this pull request Oct 6, 2016
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]>
wking added a commit to wking/image-spec that referenced this pull request Oct 20, 2016
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]>
wking added a commit to wking/image-spec that referenced this pull request Oct 20, 2016
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]>
@wking
Copy link
Contributor

wking commented Oct 25, 2016

On Fri, Sep 16, 2016 at 01:59:25PM -0700, Jonathan Boulle wrote:

Let's resolve this via #318.

I've closed #318 because there seemed to be a consensus around part of
what it was doing. Part of what I proposed in #318 has landed via
#349. Of the remaining bits, #408 has the wording that appears
uncontentious and #407 continues the discussion started by this PR
(which seems to still be unsettled 1).

@coolljt0725 coolljt0725 deleted the layer_could_be_empty branch October 26, 2016 01:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants