Multi-arch manifest using "application/vnd.docker.container.image.combined+json"

gistfile1.json

{
    "schemaVersion": 2,
    "target": {
        "mediaType": "application/vnd.docker.container.image.v1+json",
        "length": 7023,
        "digest": "sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7"
    },
    "dependencies": [
        
        {
            "mediaType": "application/vnd.docker.container.image.combined+json",
	    "linux":  {
                  "amd64": [{
                      "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-tar",
                      "length": 16724,
                      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
                      },
			{
                      "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-tar",
                      "length": 16724,
                      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
                      }
                   ],
                  "arm": [{
                      "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-tar",
                      "length": 16724,
                      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
                      },
			{
                      "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-tar",
                      "length": 16724,
                      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
                      }
                   ],
                  "ppc64le": [{
                      "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-tar",
                      "length": 16724,
                      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
                      },
			{
                      "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-tar",
                      "length": 16724,
                      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
                      }
                   ]
            }
        }, 
        {
            "mediaType": "application/vnd.docker.container.image.combined+json",
	    "windows":  {
                  "amd64": [{
                      "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-tar",
                      "length": 16724,
                      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
                      },
			{
                      "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-tar",
                      "length": 16724,
                      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
                      }
                   ],
                  "arm": [{
                      "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-tar",
                      "length": 16724,
                      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
                      },
			{
                      "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-tar",
                      "length": 16724,
                      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
                      }
                   ],
                  "ppc64le": [{
                      "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-tar",
                      "length": 16724,
                      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
                      },
			{
                      "mediaType": "application/vnd.docker.container.image.rootfs.diff+x-tar",
                      "length": 16724,
                      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
                      }
                   ]
            }
        }
    ],
    "labels": {
        "createdAt": "2015-06-16T16:29:07.952493971-07:00",
        "version": "3.1.4-a159+265"
    }
}

This variant seems to make the most sense to me--for any os.arch combination, it can quickly be determined by iterating over the dependencies array if (a) my os is supported for this image name, and (b) if yes to a), are there layers supporting my specific architecture.

Once determining that layers exist, the array of layer blobs is easily processed and then can be retrieved by their digest hash.

Pushing also seems reasonable as a new architecture push creates a new entry in the dependencies with the list of layer blobs and their digest & hash information, which will be available once the layer blob uploads are complete.

Yes, the traversal to the right blob entry seems perfect in this one.

The only concern I have here is, who controls content in dependencies.os.arch?

Let me put it in another way. Let's say we create an image for MySQL on amd64. So does that mean we will also get the right to add MySQL layers for arm (or any other arch) since the original image on amd64 was created by us? So anyone creates a MySQL image first pretty much controls the name for not only for one arch but now all the rest of architectures too.

Not really a big issue, but just saying that earlier when someone created a generic sounding image (e.g. ubuntu/14.04) they controlled it only for one arch. But since now we are going to support multiple architectures, we are saying anyone creates an image ubuntu/14.04 on any arch pretty much owns the image manifest for rest of the architectures, and if they decide to not support other architectures there is nothing others can do about it.

Not sure if I am missing something.

@harche This is not really the right approach. It ruins the generality of the manifest. The manifest knows nothing about operating systems or architectures. It is a distribution structure and decoupled from docker. This leaves control in docker engine's hands and keeps this stuff out of registry code.

Checkout my comments here:

distribution/distribution#62 (comment)

This defines "alternates", that can be labelled. This will provide a solid, backwards compatible approach. It is also efficient for the vast majority of users who only use linux-amd64. The target could be labelled, as well, so the primary target could be changed in the future.