JSON schema for the serialization formats

[vbatts]

Carrying over from #7 but specifically for the serialization formats.

• image JSON
• repositories JSON
• manifest.json
• <sha256 id>.json

[philips]

@vbatts deadbeef.json?

[vbatts]

poor name for a hexidecimal... i'll change it

[philips]

@vbatts this is referring to the "json" next to layer.tar?

[vbatts]

@philips nope. It's part of the next generation single config file, post docker-1.10 format.

vbatts@bananaboat ~ (master) $ docker pull docker.io/alpine:latest
latest: Pulling from library/alpine

420890c9e918: Pull complete 
Digest: sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0
Status: Downloaded newer image for alpine:latest
vbatts@bananaboat ~ (master) $ docker save docker.io/alpine:latest | tar tv
-rw-r--r-- 0/0            1145 2016-04-01 16:53 d7a513a663c1a6dcdba9ed832ca53c02ac2af0c333322cd6ca92936d1d9917ac.json
drwxr-xr-x 0/0               0 2016-04-01 16:53 eeb44f9ddc5f4336a1282f8ceef0ab934442de7b57472cdb5b058fd0926b3475/
-rw-r--r-- 0/0               3 2016-04-01 16:53 eeb44f9ddc5f4336a1282f8ceef0ab934442de7b57472cdb5b058fd0926b3475/VERSION
-rw-r--r-- 0/0             934 2016-04-01 16:53 eeb44f9ddc5f4336a1282f8ceef0ab934442de7b57472cdb5b058fd0926b3475/json
-rw-r--r-- 0/0         5040640 2016-04-01 16:53 eeb44f9ddc5f4336a1282f8ceef0ab934442de7b57472cdb5b058fd0926b3475/layer.tar
-rw-r--r-- 0/0             202 1969-12-31 19:00 manifest.json
-rw-r--r-- 0/0              89 1969-12-31 19:00 repositories

see also #54 (comment)

[stevvooe]

Probably should not carry repositories and json, as they are for pre-1.10.

[vbatts]

my big issue is that this flattens layers. Images need to be a federated DAG. This <sha256>.json/manifest.json layout requires condensing the parent config into the image.

Unless these combined layout can themselves also be layered.
But then there is no point in having multiple tar layers.

[stevvooe]

@vbatts How does this flatten layers? What we want to avoid here is having the DAG degrade to a linked list.

We can still federate with this approach. We lose the intermediary configs, but it is surprising when a single image carries all intermediary configurations. If one does want to ship the intermediaries, each intermediate can be include in the manifest.

[vbatts]

@stevvooe I understand avoiding the linked list. Perhaps it will be worth the exercise to work out the example of having a manifest, that references two of application/vnd.oci.image.serialization.combined.v1+json types. This is something that appc *.aci allows and would be powerful to bring in here.

[stevvooe]

I'm not sure why this requires another manifest type. Just reference each root config in the tag index. There is no need to maintain the linked the list -- this can be recovered by identifying common layers. aci suffers from the same "parent" degrading to linked list problem and it should be avoided for OCI.

[vbatts]

Oh sorry. I wasn't thinking of another manifest type, but rather an example
of a manifest that can allow more than one of the combined types as
objects, so those independent images do not have to be squashed and lose
the digest of their parentage.

On Fri, May 13, 2016 at 3:34 PM, Stephen Day notifications@github.com
wrote:

I'm not sure why this requires another manifest type. Just reference each
root config in the tag index. There is no need to maintain the linked the
list -- this can be recovered by identifying common layers. aci suffers
from the same "parent" degrading to linked list problem and it should be
avoided for OCI.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#56 (comment)

[vbatts]

So this is all together done or N/A
Only this notion of descriptor is needed now. See #92