From 574c9c821bdfff87cdc9b86a49cfd9ef8e35dd4a Mon Sep 17 00:00:00 2001 From: Stephen J Day Date: Tue, 17 Mar 2015 22:02:11 -0700 Subject: [PATCH] Add ROADMAP.md to the project and cleanup existing items Signed-off-by: Stephen J Day --- README.md | 2 + ROADMAP.md | 94 +++++++++++++++++++++++++++++++++++ open-design/MANIFESTO.md | 20 -------- open-design/ROADMAP.md | 41 --------------- open-design/specs/TEMPLATE.md | 52 ------------------- 5 files changed, 96 insertions(+), 113 deletions(-) create mode 100644 ROADMAP.md delete mode 100644 open-design/MANIFESTO.md delete mode 100644 open-design/ROADMAP.md delete mode 100644 open-design/specs/TEMPLATE.md diff --git a/README.md b/README.md index f0bc54d0..c93f897d 100644 --- a/README.md +++ b/README.md @@ -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 ------------ diff --git a/ROADMAP.md b/ROADMAP.md new file mode 100644 index 00000000..51a10a6a --- /dev/null +++ b/ROADMAP.md @@ -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. \ No newline at end of file diff --git a/open-design/MANIFESTO.md b/open-design/MANIFESTO.md deleted file mode 100644 index f3cd03da..00000000 --- a/open-design/MANIFESTO.md +++ /dev/null @@ -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 diff --git a/open-design/ROADMAP.md b/open-design/ROADMAP.md deleted file mode 100644 index 54e244ad..00000000 --- a/open-design/ROADMAP.md +++ /dev/null @@ -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 diff --git a/open-design/specs/TEMPLATE.md b/open-design/specs/TEMPLATE.md deleted file mode 100644 index a87ea61e..00000000 --- a/open-design/specs/TEMPLATE.md +++ /dev/null @@ -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 \ No newline at end of file