documentation: explain the download workflow in practice

[philips]

It is likely that the OCI Image Spec won't have an optional transport layer for a few more months while the TOB discusses and comes to a conclusion. But, as people start to use/implement the spec they will want advice on how to use the format with existing transport mechanisms.

The first topic to cover is how to use the OCI Image Format spec with the Docker v2 Registry API. This document will need to explain the entire process from a name to extracted on disk. @wking drew this diagram of the basic process:

We should probably create a helper oci-image-docker-registry-fetch tool to make it all concrete as well.

[runcom]

@philips is the end result of this downloader-from-docker-registryv2 an image-layout as defined here in the spec or something else?

[wking]

On Mon, Jun 13, 2016 at 07:20:10PM -0700, Antonio Murdaca wrote:

@philips is the end result of this downloader-from-docker-registryv2
an image-layout as defined here in the spec or something else?

The CAS fetching (e.g. pulling stuff from ./blobs) is part of this
download workflow. I was expecting it to setup a generic directory
(with whatever content the image author had setup, possibly with the
intention of some pre-runtime processing) 1. But if the image-spec
repository really sees a benefit to maintaining its own required
container config independent of the runtime config (#87), then the
graphic probably needs another “translate image-spec container config
to runtime-spec config” step.

[vbatts]

Closing this as https://github.com/opencontainers/distribution-spec is fully in motion.