rancher/os
1
0
Fork 1
mirror of https://github.com/rancher/os.git synced 2025-09-19 17:38:30 +00:00
Code Issues Releases Wiki Activity

migrate to upstream libcompose in one and a half go

Browse Source
This commit is contained in:
Ivan Mikushin
2015-11-26 17:41:42 +05:00
parent 1d691cd8d6
commit 5a363ab97d
1291 changed files with 40107 additions and 123532 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
vendor/github.com/docker/distribution/ROADMAP.md generated vendored
View File

@@ -103,20 +103,20 @@ via IRC or the mailing list and we can talk about adding it. The goal here is
to make sure that new features go through a rigid design process before
landing in the registry.
##### Mirroring and Pull-through Caching
##### Proxying to other Registries
Mirroring and pull-through caching are related but slight different. We've
adopted the term _mirroring_ to be a proper mirror of a registry, meaning it
has all the content the upstream would have. Providing such mirrors in the
Docker ecosystem is dependent on a solid trust system, which is still in the
works.
A _pull-through caching_ mode exists for the registry, but is restricted from
within the docker client to only mirror the official Docker Hub. This functionality
can be expanded when image provenance has been specified and implemented in the
distribution project.
The more commonly helpful feature is _pull-through caching_, where data is
fetched from an upstream when not available in a local registry instance.
##### Metadata storage
Please see the following issues:
- https://github.com/docker/distribution/issues/459
Metadata for the registry is currently stored with the manifest and layer data on
the storage backend. While this is a big win for simplicity and reliably maintaining
state, it comes with the cost of consistency and high latency. The mutable registry
metadata operations should be abstracted behind an API which will allow ACID compliant
storage systems to handle metadata.
##### Peer to Peer transfer
@@ -263,11 +263,5 @@ just the registry.
### Project Planning
Distribution Components map to Docker Platform Releases via the use of labels. Project Pages are used to define the set of features that are included in each Docker Platform Release.
| Platform Version | Label | Planning |
|-----------|------|-----|
| Docker 1.6 | [Docker/1.6](https://github.com/docker/distribution/labels/docker%2F1.6) | [Project Page](https://github.com/docker/distribution/wiki/docker-1.6-Project-Page) |
| Docker 1.7| [Docker/1.7](https://github.com/docker/distribution/labels/docker%2F1.7) | [Project Page](https://github.com/docker/distribution/wiki/docker-1.7-Project-Page) |
| Docker 1.8| [Docker/1.8](https://github.com/docker/distribution/labels/docker%2F1.8) | [Project Page](https://github.com/docker/distribution/wiki/docker-1.8-Project-Page) |
An [Open-Source Planning Process](https://github.com/docker/distribution/wiki/Open-Source-Planning-Process) is used to define the Roadmap. [Project Pages](https://github.com/docker/distribution/wiki) define the goals for each Milestone and identify current progress.