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>
- Use the ones provided by docker/go-connections, they are a drop in replacement.
- Remove pkg/sockets from docker.
- Keep pkg/tlsconfig because libnetwork still needs it and there is a
circular dependency issue.
Signed-off-by: David Calavera <david.calavera@gmail.com>
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>
This is a followup to #18839. That PR relaxed the fallback logic so that
if a manifest doesn't exist on v2, or the user is unauthorized to access
it, we try again with the v1 protocol. A similar special case is needed
for "pull all tags" (docker pull -a). If the v2 registry doesn't
recognize the repository, or doesn't allow the user to access it, we
should fall back to v1 and try to pull all tags from the v1 registry.
Conversely, if the v2 registry does allow us to list the tags, there
should be no fallback, even if there are errors pulling those tags.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
PR #18590 caused compatibility issues with registries such as gcr.io
which support both the v1 and v2 protocols, but do not provide the same
set of images over both protocols. After #18590, pulls from these
registries would never use the v1 protocol, because of the
Docker-Distribution-Api-Version header indicating that v2 was supported.
Fix the problem by making an exception for the case where a manifest is
not found. This should allow fallback to v1 in case that image is
exposed over the v1 protocol but not the v2 protocol.
This avoids the overly aggressive fallback behavior before #18590 which
would allow protocol fallback after almost any error, but restores
interoperability with mixed v1/v2 registry setups.
Fixes#18832
Signed-off-by: Aaron Lehmann <aaron.lehmann@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>
