clarify order of `layers` in image-layout

[vbatts]

There is currently no ordering about the ordering of layers in image-layout.
For that matter the bottom-up phrasing in config can be clarified a bit.

[wking]

On Wed, Sep 07, 2016 at 12:02:39PM -0700, Vincent Batts wrote:

There is currently no ordering about the ordering of layers in
image-layout.

I don't think we want to require anything about blob order in
image-layout, although I'm fine with an implementation note suggesting
tar-based instances put refs/* before blobs/*, list refs in
LC_COLLATE=C order, and list blob entries in the order they'll be
needed by the refs to allow easy single-pass unpacking.

But all of that is for tar-backed image-layout instances, and
image-layout can be backed by filesystems, HTTP servers, etc., which
are going to be using b-tree (or whatever) within each directory,
regardless of what we say in the spec ;).

[philips]

The main thing is that the config order matters but the manifest list order doesn't matter but it is more of a hint about downloading order and ideal download finish order.

[wking]

On Wed, Sep 14, 2016 at 02:26:58PM -0700, Brandon Philips wrote:

The main thing is that the config order matters but the manifest
list order doesn't.

Lots more discussion starting around 1, but I see no reason why the
manifest.layers order should not be layer-application order (which we
currently require 2).

[vbatts]

good thing for investigations. The DiffIDs in application/vnd.oci.image.config.v1+json ( and application/vnd.docker.container.image.v1+json for that matter), it turns out are not applied "bottom-most to top-most", but in fact the opposite.

Example:

FROM docker.io/busybox:latest
RUN rm /bin/mkfs.vfat && ln /bin/busybox /bin/farts
RUN rm /bin/farts && ln /bin/busybox /bin/mkfs.vfat

Then docker build -t demo . && docker save demo | tar -C ./demo/ -xv". The resulting config (in my case it is 5b0f7769f7e805592e5432261336082e99e281ba41ec9913e8a7de333ff13f10.json) has the followingdiff_ids`:

    "rootfs": {
        "diff_ids": [
            "sha256:8ac8bfaff55af948c796026ee867448c5b5b5d9dd3549f4006d9759b25d4a893",
            "sha256:e44257b6a419815e6e4337182f417e415d0f46c13bd58833775c1bfc725d2a20",
            "sha256:2eefae5b2f2efc1b3a7ddb9daec5c11cfdd7ab7ab0510b698d9e64c70df92d38"
        ],
        "type": "layers"
    }

Where:

• 8ac8bfaf... is docker.io/busybox:latest layer changeset
• e44257b... is rm /bin/mkfs.vfat && ln /bin/busybox /bin/farts changeset
• 2eefae5b... is rm /bin/farts && ln /bin/busybox /bin/mkfs.vfat changeset

Therefore, not only will this need to be correct in this image-spec, but also in the https://github.com/docker/docker/blob/master/image/spec/v1.2.md (cc @stevvooe @aaronlehmann)

[aaronlehmann]

The DiffIDs in application/vnd.oci.image.config.v1+json ( and application/vnd.docker.container.image.v1+json for that matter), it turns out are not applied "bottom-most to top-most", but in fact the opposite.

@vbatts: I think you are misunderstanding https://github.com/docker/docker/blob/master/image/spec/v1.2.md. It says:

diff_ids is an array of layer content hashes (DiffIDs), in order from bottom-most to top-most.

If you think of the layers as a stack, 8ac8bfaf... is indeed the "bottom" of the stack.

Perhaps there's a clearer way to state this?

[vbatts]

Also possible, "bottom-most to top-most" is interpretted differently by different folks and I'm the kind of idiot that this does not make any sense.

[vbatts]

@aaronlehmann that's what i'm arriving at. But haven't yet thought of a clearer way to say it.