forked from TrueCloudLab/distribution
Add ROADMAP.md to the project and cleanup existing items
Signed-off-by: Stephen J Day <stephen.day@docker.com>
This commit is contained in:
Stephen J Day
parent
ac550484be
commit
574c9c821b
5 changed files with 96 additions and 113 deletions
|
|
@ -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
|
||||
------------
|
||||
|
||||
|
|
|
|||
94
ROADMAP.md
Normal file
94
ROADMAP.md
Normal file
|
|
@ -0,0 +1,94 @@
|
|||
# Roadmap
|
||||
|
||||
This document covers the high-level the goals and dates for features in the
|
||||
docker registry. The distribution project currently has several components to
|
||||
report in the road map, which are covered below.
|
||||
|
||||
## 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
|
||||
|
||||
## Components
|
||||
|
||||
The distribution project has a few components with independent road maps and
|
||||
road maps related to the docker project. They are covered below.
|
||||
|
||||
### Registry
|
||||
|
||||
The current status of the registry road map is managed via github
|
||||
[milestones](https://github.com/docker/distribution/milestones). Upcoming
|
||||
features and bugfixes will be added to relevant milestones. If a feature or
|
||||
bugfix is not part of a milestone, it is currently unscheduled for
|
||||
implementation.
|
||||
|
||||
The high-level goals for each registry release are part of this section.
|
||||
|
||||
#### 2.0
|
||||
|
||||
Milestones: [2.0.0-beta](https://github.com/docker/distribution/milestones/Registry/2.0.0-beta) [2.0.0-rc](https://github.com/docker/distribution/milestones/Registry/2.0.0-rc) [2.0.0](https://github.com/docker/distribution/milestones/Registry/2.0.0)
|
||||
|
||||
The 2.0 release is the first release of the new registry. This is mostly
|
||||
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.
|
||||
|
||||
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))
|
||||
|
||||
#### 2.1
|
||||
|
||||
Milestone: [2.1](https://github.com/docker/distribution/milestones/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)
|
||||
|
||||
#### 2.2
|
||||
|
||||
Milestone: [2.2](https://github.com/docker/distribution/milestones/Registry/2.2)
|
||||
|
||||
TBD
|
||||
|
||||
### Docker Platform
|
||||
|
||||
To track various requirements that must be synced with releases of the docker
|
||||
platform, we've defined labels corresponding to upcoming releases. Each
|
||||
release also has a project page explaining the relationship of the
|
||||
distribution project with the docker project.
|
||||
|
||||
Please see the following table for more information:
|
||||
|
||||
| Platform Version | Milestone | Project |
|
||||
|-----------|------|-----|
|
||||
| Docker 1.6 | [Docker/1.6](https://github.com/docker/distribution/labels/docker%2F1.6) | [Project](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](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](https://github.com/docker/distribution/wiki/docker-1.8-Project-Page) |
|
||||
|
||||
### Package
|
||||
|
||||
The distribution project, at its core, 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 road map for distribution specific features that apply to more than
|
||||
just the registry.
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
Loading…
Reference in a new issue