- commenting out both the "JSON" and "token" specs, unless someone thinks they should be here
- added help, glossary, introduction and authentication documents
Signed-off-by: Olivier Gambier <olivier@docker.com>
- adding glossary
- removing empty "advanced"
- commenting out building and architecture for now
- minor text enhancements
Signed-off-by: Olivier Gambier <olivier@docker.com>
Simplified index again, to make access to information more obvious and more direct.
Added a TLDR for people in a hurry.
Signed-off-by: Olivier Gambier <olivier@docker.com>
Use cases, generalities, image naming overview.
Removed most of it from index, and some of it from other random pages.
Signed-off-by: Olivier Gambier <olivier@docker.com>
This clarifies the importance of properly setting a Go build environment when
building targets. Typically, users seem to editorialize the checkout location,
either ignoring the first section or have limited experience with the Go
development environment. We clarify the checkout requirements and point to the
documentation on how to setup Go.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
In the request parameters lists `tag` was used instead of
`reference` present in the HTTP requests paths
Signed-off-by: Vincent Giersch <vincent.giersch@ovh.net>
Catch up after 88795e0a (Lots of various golint fixes, 2014-11-17, #1)
and 65b0d73c (Move storagedriver package to registry/storage/driver,
2015-02-10, #167).
Signed-off-by: W. Trevor King <wking@tremily.us>
This PR is for issue of "email after registry webapp panic" #41, improving my
previous design (closed).
It use self setting up hooks, to catch panic in web application.
And, send email in hooks handle directly, to no use new http server and
handler.
Signed-off-by: xiekeyang <keyangxie@126.com>
This driver implements the storagedriver.StorageDriver interface and
uses Ceph Object Storage as storage backend.
Since RADOS is an object storage and no hierarchy notion, the
following convention is used to keep the filesystem notions stored in
this backend:
* All the objects data are stored with opaque UUID names prefixed
(e.g. "blob:d3d232ff-ab3a-4046-9ab7-930228d4c164).
* All the hierarchy information are stored in rados omaps, where the
omap object identifier is the virtual directory name, the keys in
a specific are the relative filenames and the values the blob
object identifier (or empty value for a sub directory).
e.g. For the following hierarchy:
/directory1
/directory1/object1
/directory1/object2
/directory1/directory2/object3
The omap "/directory1" will contains the following key / values:
- "object1" "blob:d3d232ff-ab3a-4046-9ab7-930228d4c164"
- "object2" "blob:db2e359d-4af0-4bfb-ba1d-d2fd029866a0"
- "directory2" ""
The omap "/directory1/directory2" will contains:
- "object3" "blob:9ae2371c-81fc-4945-80ac-8bf7f566a5d9"
* The MOVE is implemented by changing the reference to a specific
blob in its parent virtual directory omap.
This driver stripes rados objects to a fixed size (e.g. 4M). The idea
is to keep small objects (as done by RBD on the top of RADOS) that
will be easily synchronized accross OSDs. The information of the
original object (i.e total size of the chunks) is stored as a Xattr
in the first chunk object.
Signed-off-by: Vincent Giersch <vincent.giersch@ovh.net>
