From 574c9c821bdfff87cdc9b86a49cfd9ef8e35dd4a Mon Sep 17 00:00:00 2001 From: Stephen J Day Date: Tue, 17 Mar 2015 22:02:11 -0700 Subject: [PATCH 1/3] 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 From 121c4a2f8035b2e36d49a79259e2c94d7492272f Mon Sep 17 00:00:00 2001 From: Amy Lindburg Date: Wed, 18 Mar 2015 18:57:20 -0700 Subject: [PATCH 2/3] recast text of the page --- ROADMAP.md | 85 +++++++++++++++++++++++++----------------------------- 1 file changed, 39 insertions(+), 46 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index 51a10a6a..be302272 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,10 +1,12 @@ # 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. +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. -## Goals +* [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. @@ -13,30 +15,27 @@ report in the road map, which are covered below. - Define a strong data model for distributing docker images - Provide a flexible distribution tool kit for use in the docker platform -## Components +## Distribution Components -The distribution project has a few components with independent road maps and -road maps related to the docker project. They are covered below. +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 -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 +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 +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 @@ -50,9 +49,7 @@ Features: - 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) +#### Registry 2.1 Planned Features: @@ -62,33 +59,29 @@ Planned Features: - 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) +#### Registry 2.2 TBD -### Docker Platform +### Distribution Package -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. +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. -Please see the following table for more information: +The package itself is considered unstable. If you're using it, please take care to vendor the dependent version. -| Platform Version | Milestone | Project | +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](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) | +| 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) | -### 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 From 028fece85c472ab7633455a72ad2a43a61aa42a3 Mon Sep 17 00:00:00 2001 From: Amy Lindburg Date: Wed, 18 Mar 2015 19:02:37 -0700 Subject: [PATCH 3/3] more formatting... --- ROADMAP.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ROADMAP.md b/ROADMAP.md index be302272..fddc71b3 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -63,6 +63,8 @@ Planned Features: TBD +*** + ### Distribution Package At its core, the Distribution Project is a set of Go packages that make up @@ -75,6 +77,8 @@ For feature additions, please see the Registry section. In the future, we may br 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.