Add schema2 manifest implementation.
Add a schema2 builder that creates a schema2 manifest from descriptors
and a configuration. It will add the configuration to the blob store if
necessary.
Rename the original schema1 manifest builder to ReferenceBuilder, and
create a ConfigBuilder variant that can build a schema1 manifest from an
image configuration and set of descriptors. This will be used to
translate schema2 manifests to the schema1 format for backward
compatibliity, by adding the descriptors from the existing schema2
manifest to the schema1 builder. It will also be used by engine-side
push code to create schema1 manifests from the new-style image
configration, when necessary to push a schema1 manifest.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
When a manifest is deleted by digest, look up the referenced tags in the tag
store and remove all associations.
Signed-off-by: Richard Scothern <richard.scothern@gmail.com>
Since the daemon flag was deprecated and replaced by the daemon subcommand, the run engine should use the subcommand and only the flag for older versions
Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
Markdown linter produced an error on this page;
running markdownlint
ERROR (registry/spec/manifest-v2-2.md) frontmatter: Unexpected non-whitespace char: # Image Manifest Version 2, Schema 2
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
After running into a few nil pointer errors during development, it is clear
that having this function return nil when a hash is not available is the wrong
approach. Nearly every time, this lack of availability was due to a missing
import statement for the hash. This is always a programming error.
To avoid future confusion, we now appropriately panic when the hash function is
not imported by the application. More dynamic uses of the package should call
Algorithm.Available() before calling Algorithm.Hash() to avoid this panic.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Since the CloudFront middleware does not work without an S3 backend, it
became obvious that this documentation should exist within the S3
storage-driver documentation.
Signed-off-by: DJ Enriquez <dj.enriquez@infospace.com>
This is a follow-on to PR #62, and it borrows much of the format
from #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>
Adding a more detailed document regarding how to use CloudFront as
middleware for an s3 backed registry.
Signed-off-by: DJ Enriquez <dj.enriquez@infospace.com>
