alexvanin/distribution
1
0
Fork 0
forked from TrueCloudLab/distribution
Code Pull requests Activity

Merge pull request #270 from stevvooe/roadmap

Browse source 
Add ROADMAP.md to the project and cleanup existing items
This commit is contained in:
Stephen Day 2015-03-20 17:16:31 -07:00
commit 50393dbe22
5 changed files with 93 additions and 113 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -60,6 +60,8 @@ The new registry implementation provides the following benefits:
- pluggable storage backend
- webhook notifications
For information on upcoming functionality, please see [ROADMAP.md](ROADMAP.md).
Installation
------------

91
ROADMAP.md Normal file
View file

@ -0,0 +1,91 @@
# Roadmap
The Distribution Project consists of several components, some of which are still being defined. This document defines the high-level goals of the project, identifies the current components, and defines the release-relationship to the Docker Platform.
* [Distribution Goals](#distribution-goals)
* [Distribution Components](#distribution-components)
* [Project Planning](#project-planning): release-relationship to the Docker Platform.
## Distribution Goals
- Replace the existing [docker registry](github.com/docker/docker-registry)
implementation as the primary implementation.
- Replace the existing push and pull code in the docker engine with the
distribution package.
- Define a strong data model for distributing docker images
- Provide a flexible distribution tool kit for use in the docker platform
## Distribution Components
Components of the Distribution Project are managed via github [milestones](https://github.com/docker/distribution/milestones). Upcoming
features and bugfixes for a component will be added to the relevant milestone. If a feature or
bugfix is not part of a milestone, it is currently unscheduled for
implementation.
* [Registry](#registry)
* [Distribution Package](#distribution-package)
***
### Registry
Registry 2.0 is the first release of the next-generation registry. This is primarily
focused on implementing the [new registry
API](https://github.com/docker/distribution/blob/master/doc/spec/api.md), with
a focus on security and performance.
#### Registry 2.0
Features:
- Faster push and pull
- New, more efficient implementation
- Simplified deployment
- Full API specification for V2 protocol
- Pluggable storage system (s3, azure, filesystem and inmemory supported)
- Immutable manifest references ([#46](https://github.com/docker/distribution/issues/46))
- Webhook notification system ([#42](https://github.com/docker/distribution/issues/42))
- Native TLS Support ([#132](https://github.com/docker/distribution/pull/132))
- Pluggable authentication system
- Health Checks ([#230](https://github.com/docker/distribution/pull/230))
#### Registry 2.1
Planned Features:
> **NOTE:** This feature list is incomplete at this time.
- Support for Manifest V2, Schema 2 and explicit tagging objects ([#62](https://github.com/docker/distribution/issues/62), [#173](https://github.com/docker/distribution/issues/173))
- Mirroring ([#19](https://github.com/docker/distribution/issues/19))
- Flexible client package based on distribution interfaces ([#193](https://github.com/docker/distribution/issues/193)
#### Registry 2.2
TBD
***
### Distribution Package
At its core, the Distribution Project is a set of Go packages that make up
Distribution Components. At this time, most of these packages make up the
Registry implementation.
The package itself is considered unstable. If you're using it, please take care to vendor the dependent version.
For feature additions, please see the Registry section. In the future, we may break out a
separate Roadmap for distribution-specific features that apply to more than
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) |

20
open-design/MANIFESTO.md
View file

@ -1,20 +0,0 @@
# The "Distribution" project
## What is this
This is a part of the Docker project, or "primitive" that handles the "distribution" of images.
### Punchline
Pack. Sign. Ship. Store. Deliver. Verify.
### Technical scope
Distribution has tight relations with:
* libtrust, providing cryptographical primitives to handle image signing and verification
* image format, as transferred over the wire
* docker-registry, the server side component that allows storage and retrieval of packed images
* authentication and key management APIs, that are used to verify images and access storage services
* PKI infrastructure
* docker "pull/push client" code gluing all this together - network communication code, tarsum, etc

41
open-design/ROADMAP.md
View file

@ -1,41 +0,0 @@
# Roadmap
## 11/24/2014: alpha
Design and code:
- implements a basic configuration loading mechanism: https://github.com/docker/docker-registry/issues/646
- storage API is frozen, implemented and used: https://github.com/docker/docker-registry/issues/616
- REST API defined and partly implemented: https://github.com/docker/docker-registry/issues/634
- basic logging: https://github.com/docker/docker-registry/issues/635
- auth design is frozen: https://github.com/docker/docker-registry/issues/623
Environment:
- some good practice are in place and documented: https://github.com/docker/docker-registry/issues/657
## 12/22/2014: beta
Design and code:
- feature freeze
- mirroring defined: https://github.com/docker/docker-registry/issues/658
- extension model defined: https://github.com/docker/docker-registry/issues/613
Environment:
- doc-driven approach: https://github.com/docker/docker-registry/issues/627
## 01/12/2015: RC
Design and code:
- third party drivers and extensions
- basic search extension
- third-party layers garbage collection scripts
- healthcheck endpoints: https://github.com/docker/docker-registry/issues/656
- bugnsnag/new-relic support: https://github.com/docker/docker-registry/issues/680
Environment:
- exhaustive test-cases

52
open-design/specs/TEMPLATE.md
View file

@ -1,52 +0,0 @@
# DEP #X: Awesome proposal
## Scope
This is related to "Foo" (eg: authentication/storage/extension/...).
## Abstract
This proposal suggests to add support for "bar".
## User stories
"I'm a Hub user, and 'bar' allows me to do baz1"
"I'm a FOSS user running my private registry and 'bar' allows me to do baz2"
"I'm a company running the registry and 'bar' allows me to do baz3"
## Technology pre-requisites
'bar' can be implemented using:
* foobar approach
* barfoo concurrent approach
## Dependencies
Project depends on baz to be completed (eg: docker engine support, or another registry proposal).
## Technical proposal
We are going to do foofoo alongside with some chunks of barbaz.
## Roadmap
* YYYY-MM-DD: proposal submitted
* YYYY-MM-DD: proposal reviewed and updated
* YYYY-MM-DD: implementation started (WIP PR)
* YYYY-MM-DD: implementation complete ready for thorough review
* YYYY-MM-DD: final PR version
* YYYY-MM-DD: implementation merged
## Editors
Editors:
* my Company, or maybe just me
Implementors:
* me and my buddies
* another team working on a different approach