We've added a path mapper to support simple mapping between path objects used
in the storage layer and the underlying file system. The target of this is to
ensure that paths are only calculated in a single place and their format is
separated from the data that makes up the path components.
This commit only includes spec implementation to support layer reads. Further
specs will come along with their implementations.
To be able to support multi-level repository names, the API has been adjusted
to disabiguate routes tagged image manifest routes and tag list routes. With
this effort, the regular expressions have been defined in a single place to
reduce repitition and ensure that validation is consistent across the registry.
The router was also refactored to remove the use of subrouters, simplifying the
route definition code. This also reduces the number of regular expression match
checks during the routing process.
This commit adds regular expression definitions for several string identifiers
used througout the registry. The repository name regex supports up to five path
path components and restricts repeated periods, dashes and underscores. The tag
regex simply validates the length of the tag and that printable characters are
required.
Though we define a new package common, these definition should land in docker
core.
This changeset defines the application structure to be used for the http side
of the new registry. The main components are the App and Context structs. The
App context is instance global and manages global configuration and resources.
Context contains request-specific resources that may be created as a by-product
of an in-flight request.
To latently construct per-request handlers and leverage gorilla/mux, a dispatch
structure has been propped up next to the main handler flow. Without this, a
router and all handlers need to be constructed on every request. By
constructing handlers on each request, we ensure thread isolation and can
carefully control the security context of in-flight requests. There are unit
tests covering this functionality.
This has Errors implement the error interface, allowing it to pose as an error
itself. Use of this in the server may be minimal, for now, but it's useful for
passing around opaque client errors.
A method, PushErr, has also been add to allow arbitrary errors to be passed
into the Errors list. This keeps the errors list flexible, allowing the app to
collect and errors before we have codes properly mapped.
This commit includes the initial API router, based on gorilla mux and a test
suite ensuring the expected variables are extracted. Currently unexported, the
structure here will likely change as this definition will be shared with the
API client.
The registry currently only accepts storage driver versions with the
same major version and an equal or lower minor version as its own
current storage driver api version, but this may be changed in the
future if we decide to implement specific version cross-compatibility.
Most conditional parsing code has been moved into UnmarshalYAML
functions for simplicity
Uses the BrianBland fork of goyaml in configuration.go temporarily until
fix https://github.com/go-yaml/yaml/pull/52 is merged in
Custom storage drivers can register a factory to create the driver by
name, similar to the database/sql package's Register and Open
factory.Create returns an in-process driver if registered or an IPC
driver if one can be found, erroring otherwise
This standardizes parameter passing for creation of storage drivers
Also adds documentation for storagedriver package and children
