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

doc/spec: generic distribution content manifests #62

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
@jlhawn
Contributor

jlhawn commented Jan 13, 2015

A proposal for generic content manifests that can be used for
any type of application that can be represented as a JSON config
and a collection of blobs of data, or may be composed of other
such applications.

@vbatts

This comment has been minimized.

Show comment
Hide comment
@vbatts

vbatts Jan 14, 2015

Contributor

josh!

Contributor

vbatts commented Jan 14, 2015

josh!

@jlhawn

This comment has been minimized.

Show comment
Hide comment
@jlhawn

jlhawn Jan 14, 2015

Contributor

vincent!

Contributor

jlhawn commented Jan 14, 2015

vincent!

@stevvooe

This comment has been minimized.

Show comment
Hide comment
@stevvooe

stevvooe Jan 29, 2015

Contributor

@jlhawn Per our discussion, it may be prudent to remove the version or tag field from the manifest. The revision of the manifest should be its digest. What version it is should be provided by external tag.

Contributor

stevvooe commented Jan 29, 2015

@jlhawn Per our discussion, it may be prudent to remove the version or tag field from the manifest. The revision of the manifest should be its digest. What version it is should be provided by external tag.

@jlhawn

This comment has been minimized.

Show comment
Hide comment
@jlhawn

jlhawn Jan 29, 2015

Contributor

@stevvooe I'm loving that idea.

thumbtack-pushpin-2-md

Contributor

jlhawn commented Jan 29, 2015

@stevvooe I'm loving that idea.

thumbtack-pushpin-2-md

Show outdated Hide outdated doc/spec/manifest.md Outdated
Show outdated Hide outdated doc/spec/manifest.md Outdated
@jlhawn

This comment has been minimized.

Show comment
Hide comment
@jlhawn

jlhawn Feb 7, 2015

Contributor

@vbatts @ncdc @estesp please take a look at the draft spec document.

The way that we've outlined dependencies should enable layer federation (#88) for images, as well as the ability to verify that your content is based on other content.

Contributor

jlhawn commented Feb 7, 2015

@vbatts @ncdc @estesp please take a look at the draft spec document.

The way that we've outlined dependencies should enable layer federation (#88) for images, as well as the ability to verify that your content is based on other content.

@jlhawn jlhawn changed the title from Generic Distribution Content Manifests to doc/spec: Generic Distribution Content Manifests Feb 7, 2015

@stevvooe stevvooe changed the title from doc/spec: Generic Distribution Content Manifests to doc/spec: generic distribution content manifests Feb 7, 2015

@jlhawn jlhawn self-assigned this Feb 7, 2015

@estesp

This comment has been minimized.

Show comment
Hide comment
@estesp

estesp Feb 7, 2015

Member

So, just to make sure I'm thinking of this in the right context, this content manifest format would be an alternate, more generic format than what exists in the distribution/v2 registry today? Does the API change as well given instead of blobsums there is the more generic dependency? Or the client changes to walk dependencies to find layers (for the traditional Docker client pull case); both in dependent other content manifests, as well as the "leaf nodes" of actual layer data -- e.g. of the media type application/vnd.docker.container.image.layer+x-gtar?

Member

estesp commented Feb 7, 2015

So, just to make sure I'm thinking of this in the right context, this content manifest format would be an alternate, more generic format than what exists in the distribution/v2 registry today? Does the API change as well given instead of blobsums there is the more generic dependency? Or the client changes to walk dependencies to find layers (for the traditional Docker client pull case); both in dependent other content manifests, as well as the "leaf nodes" of actual layer data -- e.g. of the media type application/vnd.docker.container.image.layer+x-gtar?

@jlhawn

This comment has been minimized.

Show comment
Hide comment
@jlhawn

jlhawn Feb 7, 2015

Contributor

this content manifest format would be an alternate, more generic format than what exists in the distribution/v2 registry today?

Yes, we will deprecate the current format soon.

Does the API change as well given instead of blobsums there is the more generic dependency?

The next iteration of the API shouldn't change much. Today's "image-centric" api has two basic types of objects: image manifests and layer blobs. In the future everything will just be a content addressable blob in a named repository. Tags will be a collection of links in a repository (tag_name -> blob_digest). We'll also be adding detached signatures of content blobs and tags.

Or the client changes to walk dependencies to find layers (for the traditional Docker client pull case)

The client already does something like this to fetch all of the blobs listed in the manifest, but it will have to be updated to support nested manifest dependencies and content federation. It should be a relatively simple recursive content discovery and fetching algorithm.

Contributor

jlhawn commented Feb 7, 2015

this content manifest format would be an alternate, more generic format than what exists in the distribution/v2 registry today?

Yes, we will deprecate the current format soon.

Does the API change as well given instead of blobsums there is the more generic dependency?

The next iteration of the API shouldn't change much. Today's "image-centric" api has two basic types of objects: image manifests and layer blobs. In the future everything will just be a content addressable blob in a named repository. Tags will be a collection of links in a repository (tag_name -> blob_digest). We'll also be adding detached signatures of content blobs and tags.

Or the client changes to walk dependencies to find layers (for the traditional Docker client pull case)

The client already does something like this to fetch all of the blobs listed in the manifest, but it will have to be updated to support nested manifest dependencies and content federation. It should be a relatively simple recursive content discovery and fetching algorithm.

@ncdc

This comment has been minimized.

Show comment
Hide comment
@ncdc

ncdc Feb 9, 2015

Contributor

@jlhawn I read over this quickly and my first impression is LGTM, but I'd like to take a deeper look when I have some more time, hopefully later today.

/cc @aweiteka - please take a look w.r.t. layer federation

Contributor

ncdc commented Feb 9, 2015

@jlhawn I read over this quickly and my first impression is LGTM, but I'd like to take a deeper look when I have some more time, hopefully later today.

/cc @aweiteka - please take a look w.r.t. layer federation

@jlhawn jlhawn added the in progress label Feb 9, 2015

@dmcgowan dmcgowan referenced this pull request Feb 10, 2015

Closed

Tarsum insecurity #9719

Show outdated Hide outdated doc/spec/manifest.md Outdated
Show outdated Hide outdated doc/spec/manifest.md Outdated
@jlhawn

This comment has been minimized.

Show comment
Hide comment
@jlhawn

jlhawn Feb 11, 2015

Contributor

@stevvooe @titanous @ncdc I've just updated the PR with the following changes:

  • Removed the repository field.

    If we decide we want it back later as a name field, we can still add it before we lock down the first version of this manifest or add it in a later version.

  • Replaced digest field with a digests mapping object

    keyed by digest algorithm name, the values are a hex encoding of the digest.

  • Added an optional encryption field to the dependencies list.

    now you can attach info on how to decrypt the content if it is encrypted.

Contributor

jlhawn commented Feb 11, 2015

@stevvooe @titanous @ncdc I've just updated the PR with the following changes:

  • Removed the repository field.

    If we decide we want it back later as a name field, we can still add it before we lock down the first version of this manifest or add it in a later version.

  • Replaced digest field with a digests mapping object

    keyed by digest algorithm name, the values are a hex encoding of the digest.

  • Added an optional encryption field to the dependencies list.

    now you can attach info on how to decrypt the content if it is encrypted.

@dmcgowan

This comment has been minimized.

Show comment
Hide comment
@dmcgowan

dmcgowan Feb 12, 2015

Member

Without the name and tag field the manifest is no longer self describing. It would require additional information to import into an engine. If those fields may differ from the repository name/tag it is referenced by, that should be allowed and the fields should no longer be used for verification. An image should always be stored by the name and tag which the image was referenced and verified as, overwriting the value in the manifest. If this name and tag represent the image as it was built, then verifying the builder's signature would be the only point in which name and tag need to be verified.

Member

dmcgowan commented Feb 12, 2015

Without the name and tag field the manifest is no longer self describing. It would require additional information to import into an engine. If those fields may differ from the repository name/tag it is referenced by, that should be allowed and the fields should no longer be used for verification. An image should always be stored by the name and tag which the image was referenced and verified as, overwriting the value in the manifest. If this name and tag represent the image as it was built, then verifying the builder's signature would be the only point in which name and tag need to be verified.

@jlhawn

This comment has been minimized.

Show comment
Hide comment
@jlhawn

jlhawn Feb 12, 2015

Contributor

@dmcgowan We don't need the name and/or tag of content to be in the manifest, we only need the name to point to the content and for there to be a verifiable signature that ties that name to that content.

In the case of docker, when you want to install an image into the docker engine you tell it what the name of the image is and it will go get it through some discovery mechanism.

We haven't yet provided a new format that you can use with docker load and docker save yet, but I would image that to be very similar to what we have today: a repositories JSON file with the names of images but now they would point to content and signatures that can be verified with that name.

Contributor

jlhawn commented Feb 12, 2015

@dmcgowan We don't need the name and/or tag of content to be in the manifest, we only need the name to point to the content and for there to be a verifiable signature that ties that name to that content.

In the case of docker, when you want to install an image into the docker engine you tell it what the name of the image is and it will go get it through some discovery mechanism.

We haven't yet provided a new format that you can use with docker load and docker save yet, but I would image that to be very similar to what we have today: a repositories JSON file with the names of images but now they would point to content and signatures that can be verified with that name.

Show outdated Hide outdated doc/spec/manifest.md Outdated
Show outdated Hide outdated doc/spec/manifest.md Outdated
@stevvooe

This comment has been minimized.

Show comment
Hide comment
@stevvooe

stevvooe Feb 12, 2015

Contributor

What if we left the naming to a signed tag. Let's say we had tags like this:

{
    "name": "example.com/foo/bar:latest",
    "description": "A short description about this tag",
    "meta": {
        ... user defined fields ...
    },
    "targets": [
        {
            "mediatype": "application/vnd.docker.distribution.manifest.v1+json"
            "digest": "sha256:...",
            "attributes": {
                "os": "linux",
                "arch": "amd64",
                ...
            },
            ...
        }
    ]
}

I just don't see how we can have elements called "tags" and "repositories" but still have self-describing manifests. We need to drop one requirement or the other. I favor dropping the "self-describing" requirement, as its lead to poor data structure decisions (ie the "tag" field).

Contributor

stevvooe commented Feb 12, 2015

What if we left the naming to a signed tag. Let's say we had tags like this:

{
    "name": "example.com/foo/bar:latest",
    "description": "A short description about this tag",
    "meta": {
        ... user defined fields ...
    },
    "targets": [
        {
            "mediatype": "application/vnd.docker.distribution.manifest.v1+json"
            "digest": "sha256:...",
            "attributes": {
                "os": "linux",
                "arch": "amd64",
                ...
            },
            ...
        }
    ]
}

I just don't see how we can have elements called "tags" and "repositories" but still have self-describing manifests. We need to drop one requirement or the other. I favor dropping the "self-describing" requirement, as its lead to poor data structure decisions (ie the "tag" field).

Show outdated Hide outdated doc/spec/manifest.md Outdated
@stevvooe

This comment has been minimized.

Show comment
Hide comment
@stevvooe

stevvooe Jul 23, 2015

Contributor

@harche The repeat of Target is intended. In this model, we always have a target, with data around providing context to that target. You have the correct PR but we'd probably need to merge the tags and manifest PRs for this effort.

Contributor

stevvooe commented Jul 23, 2015

@harche The repeat of Target is intended. In this model, we always have a target, with data around providing context to that target. You have the correct PR but we'd probably need to merge the tags and manifest PRs for this effort.

@dmp42 dmp42 assigned stevvooe and unassigned jlhawn Jul 23, 2015

@harche

This comment has been minimized.

Show comment
Hide comment
@harche

harche Jul 29, 2015

Contributor

@stevvooe Why do we have Labels in Manifest when we already have them in Descriptor?

Also plural use of that word (Label) indicates that you want to have multiple Labels per Manifest. How do you plan to accommodate multiple OS/Arch in just map[string]string?

Contributor

harche commented Jul 29, 2015

@stevvooe Why do we have Labels in Manifest when we already have them in Descriptor?

Also plural use of that word (Label) indicates that you want to have multiple Labels per Manifest. How do you plan to accommodate multiple OS/Arch in just map[string]string?

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jul 29, 2015

Member

(apologies if this is a silly question); Are the Labels here intended to be directly copied from the labels that are set in Docker? Because those are indeed simple key/value pairs (I.e. a label with a given name can only have a single value - if it's specified multiple times, the previous value is overwritten)

Member

thaJeztah commented Jul 29, 2015

(apologies if this is a silly question); Are the Labels here intended to be directly copied from the labels that are set in Docker? Because those are indeed simple key/value pairs (I.e. a label with a given name can only have a single value - if it's specified multiple times, the previous value is overwritten)

@stevvooe

This comment has been minimized.

Show comment
Hide comment
@stevvooe

stevvooe Jul 29, 2015

Contributor

@thaJeztah This specification makes no recommendation for how the Labels are to be used. Yes, they can be directly copied, to allow user labels but they can also be used to provide resolution hints for consuming processes.

Think of this type as a flexible primitive.

@harche Labels can be present at the manifest or descriptor level. The manifest may have labels that are different from the individual target labels, such as who created it. We may even want them on tag. They are just a convention we are trying to follow from the other data structures.

I'll update the comment above, accordingly.

Contributor

stevvooe commented Jul 29, 2015

@thaJeztah This specification makes no recommendation for how the Labels are to be used. Yes, they can be directly copied, to allow user labels but they can also be used to provide resolution hints for consuming processes.

Think of this type as a flexible primitive.

@harche Labels can be present at the manifest or descriptor level. The manifest may have labels that are different from the individual target labels, such as who created it. We may even want them on tag. They are just a convention we are trying to follow from the other data structures.

I'll update the comment above, accordingly.

@harche

This comment has been minimized.

Show comment
Hide comment
@harche

harche Jul 29, 2015

Contributor

@stevvooe Thanks for the clarification, I was under assumption that Labels would serve to declare only OS/Arch information.

Contributor

harche commented Jul 29, 2015

@stevvooe Thanks for the clarification, I was under assumption that Labels would serve to declare only OS/Arch information.

@DieterReuter

This comment has been minimized.

Show comment
Hide comment
@DieterReuter

DieterReuter Aug 5, 2015

@stevvooe I've digged a little bit deeper into the label usage, maybe we could use this quite well for the different ARM types and all other different CPU architectures.
Example 1: Raspberry Pi 1

  "platform": {
    "os": "linux"  
    "arch": “arm”,
    "model": “armv6l”,
  }

Example 2: ARMv8 (64-bit) machine

  "platform": {
    "os": "linux"  
    "arch": “arm”,
    "model": “aarch64”,
  }

These are all the detailled infos a Docker engine would need to push or pull the appropriate image, but they should be mandatory (the labels os and arch at least) for future versions. For amd64 there’s no need to use the label model and we do have the same functionality like today in v1.

All the values could be easily and automatically gathered:
os: from GOOS env
arch: from GOARCH env
model: from uname -m (could be done from GO as well with using a simple kernel syscall, which works on Linux and Android as well)

In this case the logic to select the right image architecture is only necessary to be implemented in the Docker engine for a pull or a push. Even the compatibility logic will only be needed in the engine. So we could be very clean within the Docker registry itself, just storing the platform labels and use these labels for fetching the right images which are matching the requested platform where the Docker engine is running.

Here is an example how to use uname -a from GO: https://github.com/DieterReuter/osarch/blob/master/osarch_linux.go#L10

I did also run some recent tests on different devices (Mac, Linux and even Android) with a small basic implementation in GO. https://github.com/DieterReuter/osarch#results-on-different-devices
This tool could be extended for Windows too and could be improved to a general libosarch package/lib to gather these informations easily (maybe with a reference implementation in GO and C).

As I already said, that's just a rough idea how to determine the platform labels in an easy and elegant way. And if anyone is in the need of more specific labels, like a byte order or ABI, he is free to just add new additional labels in his container runtime. There no need to change the behaviour of the Docker registry.

DieterReuter commented Aug 5, 2015

@stevvooe I've digged a little bit deeper into the label usage, maybe we could use this quite well for the different ARM types and all other different CPU architectures.
Example 1: Raspberry Pi 1

  "platform": {
    "os": "linux"  
    "arch": “arm”,
    "model": “armv6l”,
  }

Example 2: ARMv8 (64-bit) machine

  "platform": {
    "os": "linux"  
    "arch": “arm”,
    "model": “aarch64”,
  }

These are all the detailled infos a Docker engine would need to push or pull the appropriate image, but they should be mandatory (the labels os and arch at least) for future versions. For amd64 there’s no need to use the label model and we do have the same functionality like today in v1.

All the values could be easily and automatically gathered:
os: from GOOS env
arch: from GOARCH env
model: from uname -m (could be done from GO as well with using a simple kernel syscall, which works on Linux and Android as well)

In this case the logic to select the right image architecture is only necessary to be implemented in the Docker engine for a pull or a push. Even the compatibility logic will only be needed in the engine. So we could be very clean within the Docker registry itself, just storing the platform labels and use these labels for fetching the right images which are matching the requested platform where the Docker engine is running.

Here is an example how to use uname -a from GO: https://github.com/DieterReuter/osarch/blob/master/osarch_linux.go#L10

I did also run some recent tests on different devices (Mac, Linux and even Android) with a small basic implementation in GO. https://github.com/DieterReuter/osarch#results-on-different-devices
This tool could be extended for Windows too and could be improved to a general libosarch package/lib to gather these informations easily (maybe with a reference implementation in GO and C).

As I already said, that's just a rough idea how to determine the platform labels in an easy and elegant way. And if anyone is in the need of more specific labels, like a byte order or ABI, he is free to just add new additional labels in his container runtime. There no need to change the behaviour of the Docker registry.

@jlhawn

This comment has been minimized.

Show comment
Hide comment
@jlhawn

jlhawn Sep 17, 2015

Contributor

Closing in favor of #993 by @estesp

Contributor

jlhawn commented Sep 17, 2015

Closing in favor of #993 by @estesp

@jlhawn jlhawn closed this Sep 17, 2015

aaronlehmann added a commit to aaronlehmann/distribution that referenced this pull request Oct 5, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

aaronlehmann added a commit to aaronlehmann/distribution that referenced this pull request Oct 5, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

aaronlehmann added a commit to aaronlehmann/distribution that referenced this pull request Oct 14, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

aaronlehmann added a commit to aaronlehmann/distribution that referenced this pull request Oct 14, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

aaronlehmann added a commit to aaronlehmann/distribution that referenced this pull request Oct 14, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

aaronlehmann added a commit to aaronlehmann/distribution that referenced this pull request Oct 14, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

aaronlehmann added a commit to aaronlehmann/distribution that referenced this pull request Oct 14, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

aaronlehmann added a commit to aaronlehmann/distribution that referenced this pull request Oct 16, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

aaronlehmann added a commit to aaronlehmann/distribution that referenced this pull request Dec 18, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

aaronlehmann added a commit to aaronlehmann/distribution that referenced this pull request Dec 18, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

aaronlehmann added a commit to aaronlehmann/distribution that referenced this pull request Dec 18, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

aaronlehmann added a commit to aaronlehmann/distribution that referenced this pull request Dec 18, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

BrianBland added a commit to BrianBland/distribution that referenced this pull request Dec 28, 2015

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>

BrianBland added a commit to BrianBland/distribution that referenced this pull request Jan 6, 2016

docs/spec: Proposal for new manifest format
This is a follow-on to PR docker#62, and it borrows much of the format
from docker#993, but uses specific formats for the image manifest and manifest
list (fat manifest) instead of a combined generic format.

The intent of this proposed manifest format is to allow multi-arch, and
allow for full content-addressability of images in the Docker engine.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment